Forgot your password?
typodupeerror
Google Businesses The Internet

Is Anyone Using the Google Web Toolkit? 470

Posted by kdawson
from the seemed-like-a-good-idea dept.
eldavojohn writes "After seeing some applications from Google and participating in the Google Codejam (which seems to be built using the GWT), I kind of expected to see websites spring up left and right based off the GWT. Well, it's been a year and a half since they open sourced it and I have to admit that I am more than a little disappointed by its low profile in the UI community. I've been trolling their blog and have seen a few books out on it. But the one thing I'm not seeing is its use outside of Google. I've worked through the examples and tutorials at home and though I've been impressed with the speed, I am disturbed by the actual result — a whole ton of generated Javascript. But this is the first UI technology I've found where I can write in the native language of the server (Java) to generate and unit-test the UI code. Aside from Google's use and the games of Ryan Dewsbury like KDice & GPokr, does anyone know of major sites using the GWT? If you don't and you've used it yourself, why isn't it taking off? Is it too immature? Is it a solution to a problem that already has too many solutions? Is it fundamentally lacking in some way?"
This discussion has been archived. No new comments can be posted.

Is Anyone Using the Google Web Toolkit?

Comments Filter:
  • by Anonymous Coward on Wednesday July 23, 2008 @12:59AM (#24299401)

    Because a big company open sources something we're supposed drop what we're doing and run to the next best thing?

    JavaScript libraries and toolkits multiply faster than rabbits, there's a new "framework" coming out each week, and some of them had strong developer support (i.e. people willing to answer my stupid questions in forums) long before Google came out with their stuff.

    Not that it's bad or anything, but in the end it's all JavaScript anyway, and learning two different ways to get to the same goal (an interactive site) is generally pretty low on everybody's priority list.

    Are you using Google Sparse Hash by the way? Why not?

    • by Kristoph (242780) on Wednesday July 23, 2008 @03:06AM (#24300089)

      The wacky Javascript that GWT generates is fine if your a Googler and understand and can fix issues that might occur but there many other cleaner solutions out there that mere, non kool-aid drinking, mortals can much more effectively work with.

      • by IamTheRealMike (537420) * <mike@plan99.net> on Wednesday July 23, 2008 @07:31AM (#24301875) Homepage

        D'oh. I'm a Googler but seriously, nobody is meant to understand compiled JavaScript. Good thing then, that GWT provides a mode in which it does not minify the code, so if something does go wrong in the generated JS you can track it down in the human readable version.

        There are a lot of GWT myths floating around here. I don't work on it but I did adopt it for a project of mine recently, and it's worked out pretty well so far. Myths I saw reading this thread, in no particular order:

        • No nice widget toolkits like Qt or GTK+: GWT Ext seems to provide this [gwt-ext.com]. Haven't used it myself though.
        • Content can't be crawled: well, GWT is meant for applications rather than websites, but you can embed anything you want in the bootstrap HTML which will be crawled just like normal. If you have an app in which you want to expose a giant database of things to a crawler then whilst you can still do that with GWT, you don't get as much of the benefit.
        • Can't use "traditional" frameworks like jQuery: a lot of the better JavaScript frameworks have equivalents in GWT actually, for instance, GWTQuery does what jQuery does (let you select nodes from the DOM using CSS selectors) - but it uses the GWT compiler magic to produce optimal code for each browser. For instance, it can compile your CSS expression into an XPath query for browsers that support that, or do things the long winded way for browsers that don't. Thus your user gets a maximally efficient app.

        I suspect you'll see GWT used more and more in future. It's such a radically different approach it takes some getting used to, and whilst it does support evolving an existing codebase towards it, it's still easier if you start from scratch. Still, I do believe that GWT is one of the nicest open source things Google has released for a long time. It's very well thought out and is designed to be very efficient, which is important for any non-trivial web app.

        • Re: (Score:3, Insightful)

          by nostriluu (138310)

          What about accessibility? That's a pretty huge gap. You're excluding a lot of users just to have whizzy controls, and for some industries it's the law that you have to have accessible Web pages.

          Making a second set of pages for accessibility is a poor choice. And as a benefit of making pages accessible, they usually work well in mobile browsers.

          This is why I don't use a comprehensive framework like GWT, aside from the lack of ultimate control over layout and functionality.

          • by HommeDeJava (986338) on Wednesday July 23, 2008 @11:19AM (#24304979)
            Here's a quick overview of what has been done in GWT 1.5 in terms of accessibility support:

            * Keyboard support to Menus and TabBars

            * Added ARIA roles/states to MenuBar/MenuItem, Tree/TreeItem, TabBar/TabPanel, CustomButton/ToggleButton/PushButton

            * Screen readers are now able to identify and speak the content of these widgets

            * Improved tab navigation

            * New API to set ARIA roles/states on Elements (still experimental)

      • Re: (Score:3, Interesting)

        by darkvad0r (1331303)
        Well, I work for a large TV company in France and the fact that Java code is easily maintainable and that it is our language of choice for server-side stuff makes GWT the ideal choice for GUIs. We have deployed 5 large web applications built with GWT and the users are really pleased with the experience. That said, we do control the deployment environment up to a certain point (everybody has JS enabled on its workstation and the workstations are fairly recent) and we don't mind about spiders not being able
    • by Jimmy_B (129296) <.gro.hmodnarmij. .ta. .todhsals.> on Wednesday July 23, 2008 @04:03AM (#24300381) Homepage

      GWT is NOT a Javascript library! It's a Java library and a Java-to-Javascript compiler; it saves you from having to learn or work with Javascript at all. This means that you write your client in Java, same as your server-side code, and get to use a real Java debugger.

      • by vidarh (309115) <vidar@hokstad.com> on Wednesday July 23, 2008 @04:33AM (#24300533) Homepage Journal
        That's assuming your server-side is written in Java, which is a pretty big damn if when it comes to web applications.
  • by QuantumG (50515) * <qg@biodome.org> on Wednesday July 23, 2008 @12:59AM (#24299405) Homepage Journal

    is that everyone wants to roll their own.

    • by SanityInAnarchy (655584) <ninja@slaphack.com> on Wednesday July 23, 2008 @01:23AM (#24299567) Journal

      Mostly because no one's really gotten it right yet.

      That, and we still don't have any set of frameworks which have built up enough to be difficult to replace. Nothing close to, say, GTK+, Qt, WinForms, Cocoa, etc.

      • Re: (Score:3, Insightful)

        by bigtangringo (800328)

        The barrier to entry for web development (even web 2.0) is much lower than your standard desktop environment. You can build damn near anything out of a dozen components (tags) and a little more than two dozen properties (styles).

        • Except that similar RAD tools exist for desktop environments, too -- Visual Basic being the most famous, but there are others. The only advantage of a web app here is that it's cross-platform -- but you would also get that with, say, Shoes [whytheluckystiff.net].

          No, the cool, unique properties of a web app are pretty much entirely the user experience -- the fact that there's nothing to download, and no updates to manage.

          That said, I'd develop just about anything as either a web app or a commandline tool, mostly because these are

          • by try_anything (880404) on Wednesday July 23, 2008 @02:48AM (#24299975)

            No, the cool, unique properties of a web app are pretty much entirely the user experience -- the fact that there's nothing to download, and no updates to manage.

            I develop a rich client application for internal corporate use, and I find that casual users really miss web-style navigation. I get a lot of requests that are essentially requests to simulate a web experience by providing a bunch of screens that users can click through to find the information they want, instead of using traditional (perhaps formerly traditional?) GUI ways of exposing functionality.

            Also, these days, mashups and Greasemonkey scripts really magnify the value of web applications. Deprecating a web application in a big company can be nearly impossible because you find out that there are a bunch of business processes that depend on mashups and fancy Greasemonkey scripts that have been hacked together (usually by interns, IT guys, and other random people) and that provide substantial business value.

            • Re: (Score:3, Insightful)

              by leenks (906881)

              Surely that suggests that the design of your traditional GUI approach is wrong (and indeed modern GUI design is somewhat different to the approaches of yesteryear, involving many techniques borrowed from different domains).

              Rich clients aren't meant to be like traditional applications either - they are supposed to be what their name suggests, ie a client to some remote functionality that gives a richer experience than a traditional web application.

              How you expose that functionality is critical if you want use

            • Re: (Score:3, Interesting)

              by encoderer (1060616)

              I've noticed the same thing.

              I'm a partner in a mid-sized software dev firm. We're a job shop that is slowly bringing our own product to market.

              Anyhoo, we wrote a route costing app for a certain airline (hint: It wasn't a foreign airline) about 5 years ago and we've upgraded the app about once a year since.

              Last year we were asked how much it would cost to re-write as a web app.

              It's not a broad app in terms if its function. But it's got a set of algorithms that are very tightly wound and the best guess of my

              • What part of "Let the end user successfully use the application" doesn't register?

                The whole point of whatever you designed is presumably to get something done. With the computer. If the users are more productive with a "web style" interface then go ahead and make a web style interface. If users are more productive using Microsoft Bob then code it to look like Bob.

                It may seem like a silly affectation to you but to computer naive users any change in the interface (the Internet to them) is scary. You ca

      • by Fred_A (10934) <fred@@@fredshome...org> on Wednesday July 23, 2008 @04:31AM (#24300519) Homepage

        Mostly because no one's really gotten it right yet

        Presumably, everybody is waiting for Web 2.1 or 2.2.

    • by Atario (673917) on Wednesday July 23, 2008 @02:25AM (#24299865) Homepage

      The secret shame of Web 2.0^W^W^W^W programming in general

      Fixed that for you.

  • To me, (Score:5, Interesting)

    by bucky0 (229117) on Wednesday July 23, 2008 @01:03AM (#24299433)

    To me, the biggest problem is abolutely no fallback to non-javascript browsers. I'm not so much worried about users, but search engine bots won't be able to spider me and drive traffic to me.

    • Re: (Score:3, Informative)

      by bucky0 (229117)

      let me preemptively correct that. I _do_ care about users, but most of my users are tech-savvy and have up-to-date browsers. The ones who don't are in a minority.

      • Re:To me, (Score:5, Interesting)

        by VoyagerRadio (669156) <harold.johnson@gmail.com> on Wednesday July 23, 2008 @01:17AM (#24299525) Homepage Journal
        Exactly. Man, when I finally decided to really get down and dirty with HTML (translation: when I decide to learn all aspects of HTML and its related technologies), I got all hardcore over XHTML and CSS. I spent more time validating my site to strict XHTML than making the site prettier (not to mention producing better content). After a few years of my addiction to usability and valid forward-and-backwards-compatible code and Jeffrey Zeldman articles, I finally realized that I was wasting my time. Users don't want valid code: they just want pretty, moving pictures and sound (that they can easily turn on and off, of course).
        • Re:To me, (Score:5, Insightful)

          by FinestLittleSpace (719663) * on Wednesday July 23, 2008 @01:49AM (#24299717)

          It's not about valid code, it's about accessibility.

          Your attitude is the same as some dick opening a shop with spiral stairs leading up to it 'cos it's prettier, right?' Yeah, except for those wheelchair users.

          There not be many disabled people compared to 'able', but if you ever become disabled one day, you'll be shouting from the roof for more accessibility just like all the rest.

          • Re:To me, (Score:5, Funny)

            by Anonymous Coward on Wednesday July 23, 2008 @03:25AM (#24300175)

            How do you get to the roof in a wheel chair?

      • Re: (Score:3, Interesting)

        by Anonymous Coward

        > tech-savvy

        It's likely that the MOST tech-savvy are the ones disabling javascript. The novices haven't even heard of it, leave alone be familiar with its particular annoyances, and have it enabled by default.

        I block flash for 99.8% of all web sites, only enabling it on a case by case basis with the FF extension. If a site doesn't work without javascript, I usually just don't go there. This (and adblock) makes the web remarkably less annoying.

        • by penix1 (722987)

          The problem is massive commercialization of the internet has led to massive abuses of javascript. Everyone is scrambling for their piece of the pie. The pop-up problem is an example of this abuse. The user shouldn't have to go to such extreams just to have a decent experience let alone a safe one. I knew the internet would go to hell in a handbasket when http://www.tampax.com/ [tampax.com] went live. It's a cat and mouse game with everyone pushing for the attention of the user all the while the user's wishes are left ou

      • by gd2shoe (747932)

        You missed his point entirely.

        Web browsers aren't the only things which download web pages. Web crawlers such as google, yahoo, and msn also download your pages. These crawlers wont ever render a page. They only strip out searchable content. If someone isn't careful about non-visual text (alt-texts and such) it is possible to get a very low search engine ranking for an otherwise excellent site. The same is true for javascript (read: ajax) generated content.

        Personally, I think this scenario is rare. Bu

      • ... than browsing with elinks? ... or with noscript?

    • Really? I know Gmail does -- does GWT actually not do this, or are you making an uninformed statement about AJAX in general?

    • Re: (Score:3, Insightful)

      by GWBasic (900357)

      To me, the biggest problem is abolutely no fallback to non-javascript browsers. I'm not so much worried about users, but search engine bots won't be able to spider me and drive traffic to me.

      Your issue has nothing to do with GWT. JavaScript only has fallback for non-JavaScript browsers if you write fallback HTML; and GWT is no different.

      The same applies for spiders; your content (either static or dynamic) needs to be in the HTML part in order for a spider to see it. If your content is loaded dynamically through AJAX then no spider will see it.

      For fallback and spiders, JavaScript (either hand-written or compiled from GWT) can manipulate pre-rendered HTML. The pre-rendered HTML can either be s

    • "To me, the biggest problem is abolutely no fallback to non-javascript browsers. I'm not so much worried about users, but search engine bots won't be able to spider me and drive traffic to me."

      So if you use the tool Google recommends to create your website, Google won't index it properly and you will fall off Google rankings?!?
  • It's used... (Score:3, Interesting)

    by AKAImBatman (238306) <akaimbatman@[ ]il.com ['gma' in gap]> on Wednesday July 23, 2008 @01:10AM (#24299469) Homepage Journal

    ...just not as much as you might expect. Part of the issue is that it's designed for when you develop your application from scratch. Generally with the intent of developing a desktop replacement webapp. The only problem is that not many companies are investing in such apps. They're investing in using DHTML/AJAX to make their sites more interactive rather than replacing the HTML interface outright. In that situation, GWT is not the ideal solution. (e.g. For quite a while, you couldn't even have more than one widget per page!) It works though, so you'll find it pop up here and there.

    On a personal level, I'd rather see the effort spent learning GWT applied to learning Javascript and the web technologies instead. There are a lot of frameworks out there, but none of them are actually needed in 90% of the cases. What we actually need are programmers who know how to write maintainable and highly interactive Javascript components for their sites. Such knowledge allows them to get the job done faster than mucking about with Yet Another Framework(TM) designed to take a cannon to the problem of killing a fly.

    • Re:It's used... (Score:5, Insightful)

      by John_Booty (149925) <johnbooty.bootyproject@org> on Wednesday July 23, 2008 @01:32AM (#24299613) Homepage

      On a personal level, I'd rather see the effort spent learning GWT applied to learning Javascript and the web technologies instead. There are a lot of frameworks out there, but none of them are actually needed in 90% of the cases. What we actually need are programmers who know how to write maintainable and highly interactive Javascript components for their sites. Such knowledge allows them to get the job done faster than mucking about with Yet Another Framework(TM) designed to take a cannon to the problem of killing a fly.

      It's not learning Javascript that's the big obstacle to coding your own solutions sans framework; it's dealing with the browser compatibility issues. Frameworks largely compensate for that.

      If you write your own non-trivial Javascript code, you have to test on IE 6/7/8, FF 2/3, Opera 9.whatever, Safari 2/3, etc etc etc etc.

      • Re: (Score:3, Interesting)

        by AKAImBatman (238306)

        It's not learning Javascript that's the big obstacle to coding your own solutions sans framework; it's dealing with the browser compatibility issues. Frameworks largely compensate for that.

        The ideal solution in that case is NOT frameworks. It's to have runtime patches available that make your code run predictably on all browsers. That way if you need to support a new browser, you just add a new patch so that it functions predictably. (If necessary.) Since such patches tend to function based on whether or no

        • Re: (Score:3, Informative)

          GWT isn't a traditional Javascript framework. It doesn't have if...else clauses meant to give browser compatibility, but rather optimized chunks of heavily optimized Javascript which are selected based on locale and browser on initial load.

          It's not fair to say that GWT has the same disadvantages as toolkits like Dojo, Ext, Prototype, etc, since it's really not the same thing.

          Also, it's one of the few open "Web 2.0" frameworks to have a really nice visual designer [instantiations.com] available.

  • by j_kenpo (571930) on Wednesday July 23, 2008 @01:11AM (#24299479)

    We built a Proof of Concept Report Designer and Report Viewer on top of BIRT using GWT for the interface. It had some cool features, like multi-user real-time report development, versioning, and tie ins to the commercial report repository that the company that built BIRT sells. It had a real nice WOW factor to it, but in the end, it was just a pretty POC that we could show at conferences, it would never replace the desktop version due to responsiveness (imagine, an Eclipse app that is more responsive than something else...) IMHO, web technology is just catching up in the UI space to where desktop apps were like 15 years ago, and Web 2.0 is still a tacky buzzword. To do some things that are trivial in a desktop app requires a lot of convoluted steps (callbacks, etc). And even things that would be done the same way still requires a network round trip to get information that desktop apps don't suffer (simple tasks like dynamic drop-down or list population). GWT is a step in the right direction, and the ability to debug in an IDE both client and server side components is very nice.

    • To do some things that are trivial in a desktop app requires a lot of convoluted steps (callbacks, etc).

      Don't tell me you've never used callbacks in a desktop app?

      And even things that would be done the same way still requires a network round trip to get information that desktop apps don't suffer (simple tasks like dynamic drop-down or list population).

      Except usually the point of doing this in a web app, as opposed to a desktop app, is that the data is stored somewhere else. If a desktop app would be doing the same thing -- making a SQL call to a database, or accessing a shared file on a network store -- then you lose nothing by doing this with the web app.

      Unless you aren't smart enough to cache the results in the web app, the way you would for a desktop app... And even then, I suspect that the br

      • by j_kenpo (571930)

        The point was not "OMG big scary Callbacks", it was that the inherent nature of the platform requires steps that wouldn't be necessary in a desktop app. Callbacks were just an example. Data can still be stored "someplace" else in a desktop app and still have shorter number of hops. Using the DB example, a desktop app, you would have communication from App -> DB that could be handled in a single method. In a GWT app, you have Web Client -> Web Server -> DB, handled with at the minimum a method on th

  • Seems Too Heavy (Score:5, Interesting)

    by telbij (465356) on Wednesday July 23, 2008 @01:11AM (#24299483)

    I'm a long time web developer but I've never even cracked open the box on GWT, so take this with a grain of salt.

    The idea of depending on generated javascript scares me. I'm against writing Javascript in Java, Ruby, Python or anything else. Javascript is just too much of a beast to debug to leave everything up to an opaque framework, and I want to be able to get my hands dirty. I like the smaller and more traditional open-source style frameworks. Prototype, jQuery, MooTools, even Dojo just scare me a lot less.

    It could be totally irrational, and it also could be the fact that I tend to build web applications that need minimal state and pretty basic AJAX interactions. Nothing anywhere near as dense as, say, Gmail. If the right project came along I'd definitely give it a more serious look.

    • by pohl (872) on Wednesday July 23, 2008 @10:34AM (#24304149) Homepage

      I've used GWT to develop a pretty sophisticated server-side piece of a vertical market product. I approached GWT with much of the same trepidation as you have expressed. In the end I just had to "let go" and think of Javascript as an assembly language. (After all, I've been ignoring assembly language all these years, why not ignore Javascript?)

      Now that our product is in a mature phase, and looking back at what we've built, I'm amazed by the brilliant design tradeoffs chosen by the GWT team at Google. Kudos.

      The generated Javascript ended up being very easy to debug, and exceedingly lightweight. Since the source language is static, the compiler is able to leave out every feature that you didn't use. Their "Pay As You Go" philosophy actually works.

      The only major caveat that comes to mind is that GWT shines for "web apps" more than for "web sites", which may account for why the submitter isn't seeing GWT "in the wild". It's important for sites to be spiderable [wikipedia.org], and you get the most leverage out of GWT when you're building an all-in-one-page DHTML rich-client application, not a site. It's still useful for sites, but then you'd be hunting squirrels with a bazooka.

      But that can be fun, too.

  • by Cyberax (705495) on Wednesday July 23, 2008 @01:13AM (#24299501)

    There's a lot of corporative GWT-apps because it's, probably, the best toolkit for rich-client web applications.

    However, it's not used much in the public web because most sites just don't need that kind of user interfaces.

    Also, GWT is incompatible with web spiders.

    • by vagabond_gr (762469) on Wednesday July 23, 2008 @05:11AM (#24300757)

      I couldn't agree more. There 2 very different ways to use Ajax:
      1) have a traditional site and embed small "Ajax goodies" here and there, like digg does with comments.
      2) have a 100% Ajax site, like GMail.

      Cleary, GWT is good for (2), not (1). Now ask yourself, how many full Ajax sites do you know? GMail, Yahoo mail, a couple more? So it's not a problem with GWT, it's just that the idea of a full Ajax site is not suitable for the open web, it is much more useful for intranet and web-apps use.

    • Re: (Score:3, Interesting)

      by mcvos (645701)

      There's a lot of corporative GWT-apps because it's, probably, the best toolkit for rich-client web applications.

      There's also Java Applets.

      Admittedly never got the popularity Sun originally hoped for, but if you want filthy rich clients, Java applets can do that for you.

  • I have used it for a transit/maps mashup application and it worked like a charm. I would agree with those who argue that it's great for writing new web-based apps from scratch and less for adding incremental dynamic features to largely static content sites.

  • by dubl-u (51156) * <2523987012@p[ ].to ['ota' in gap]> on Wednesday July 23, 2008 @01:18AM (#24299527)

    I spent a month using it to build something in April 2007, and it was a big ol' pain. Getting something that roughly worked wasn't too bad, but there were a number of bugs and quirks that cost me time and headache.

    Also, their rendering components generated an awful lot of hard to manage HTML and CSS. There were several display issues I never got quite right, and when I asked a front-end whiz to help me out, he had some very unkind things to say about the generated code.

    My end impression was that it was about 0.7 in quality, needed a lot of polishing, and was really only useful for Java people who didn't want to understand what was actually going on in the browser. Were I to do that project over again, I'd instead just use something like JQuery [jquery.com], and learn how to do JavaScript properly, rather than hoping a framework would save me from my ignorance.

  • by bogaboga (793279)

    ...it's been a year and a half since they open sourced it and I have to admit that I am more than a little disappointed by its low profile in the UI community...

    There are more than 67 million businesses in the world and I wonder how many of those you have polled. Can you tell us how many of those businesses you have surveyed?

    If you don't and you've used it yourself, why isn't it taking off? Is it too immature?

    If you are asking a question and providing the answer, I wonder why you even ask.

    In your submission, you should at least have informed us about Google's view on this issue is, if you wanted us to take you serious. Be serious please.

  • by Pinchiukas (828697) <pinchiukas&gmail,com> on Wednesday July 23, 2008 @01:26AM (#24299581) Journal
    Probably the most popular social website in Lithuania uses GWT - www.one.lt [www.one.lt].
    • Re: (Score:3, Funny)

      by Anonymous Coward

      wow [imageshack.us]

  • by Gazzonyx (982402) on Wednesday July 23, 2008 @01:29AM (#24299599)
    My biggest problem is that I'm studying frameworks, JITs, libraries, languages and spinoff languages nearly constantly, and they're multiplying faster than I can even say I've given a look at them.

    Just a few weeks ago, I had an itch to scratch, so I figured I'd bang out a quick fix in my most well known language, Java (I started Java around early 1.4 days back in high school, as they were fading out C++, although I passed the AP test in C++ the last year it was given in that language). I figured I'd expand my horizons a bit and learn Java Enterprise, as I already have a really solid background in Standard Edition. After compiling a JBoss server, Ant, and getting JBoss studio (read: a day later), I decided to jump right in. Several hours later and a trip to the book store later, I realized that I needed more background info and got the hardcopy version of the Java EE Tutorial. It assumes that you know, XML, RPC, SQL, Hibernate, ODBC, etc. I've got experience with a good deal of it, and it's still a daunting task to learn just the architecture of the Java EE suite. This is before even thinking about writing a bit of code. The amount of time that you have to invest and the steepness of the learning curve is, frankly, intimidating!

    My Eclipse install is a gigabyte, ATM, I've got about 10 IDEs, 3 SQL servers, and a directory called 'programming' with a range of tools and a sub directory called 'libraries' which has SDKs that I've downloaded and intend to getting around to trying. I bought Flex2 and Expression Studio last summer and have barely had time to play with them, and both have new versions out already. Then I've the SDK for Android, Flex (looks like another month of studying the architecture just to hit the ground running), and AIR, all sitting around for me to have time to play with them, before they're obsolete. Not to mention another Java release in the wings.

    There are simply too many frameworks, languages, and methods for anyone to be well versed in more than a small number of them. And they come and go so quickly, I don't know if I should invest time in what might become the next Laszlo (looked really, really, cool - never got any traction). Google offers APIs and SDKs in what, half a dozen languages, and half of them are just interfaces to XML? What's wrong with libcurl?

    I've only got so much time, and lately everything falls in to one of three categories, "cool, and worth the time investment", "cool, but probably only for my own hacking around", and "...what the crap does it do?".

    Am I the only one with this issue? I admit, I spend a lot of time playing with Linux distros, too, so I have less time than others. Oh, yeah, and the four or five languages I'm expected to use every semester, and the three or four that I use at work on a monthly basis.
    • After compiling a JBoss server, Ant, and getting JBoss studio (read: a day later), I decided to jump right in.

      Here's a hint for you: Use Glassfish [java.net]. Your life will be about 1000x easier.

      Here's another hint: No matter what anyone tells you, AVOID JAVA SERVER FACES LIKE THE PLAGUE. The API will not help you.

      Hope that helps. :-)

      • Re: (Score:3, Interesting)

        by Fuzuli (135489)

        Sorry, just have to ask: What do you recommend instead of jsf? This comes from a guy who has to choose a java web stack for an upcoming project, that'll have to scale. No need for a flame war, just asking for a short answer here :)

    • by try_anything (880404) on Wednesday July 23, 2008 @02:28AM (#24299881)

      As a student, don't bother learning frameworks with the idea that you will use them later. There are only two good reasons to learn a framework. The first is to use it right away on a project you want to get done. The second is to get experience with frameworks in general and particular types of frameworks. It is valuable to be able to:

      • Learn a framework quickly.
      • Understand the advantages and disadvantages of frameworks, as opposed to lightweight approaches.
      • Evaluate and compare frameworks for a given task.

      Knowing a framework is, in itself, pretty useless unless you are going to use it right away or apply for one of those mythical Monster.com jobs where companies hire people to work with version 2.37a of Ridiculously Specific Technology Z. I don't know of any companies that actually hire that way unless they need a consultant to work with a legacy system whose developers have long since disappeared. In other words, you won't be hired for your experience with a specific framework until that framework is obsolete.

      Now, setting aside the proper way to study frameworks, why are you even thinking about frameworks as an "investment" at your age? You sound like you're in way too much of a hurry. If you learn one distributed N-tier application framework, one web application framework, and one rich client application framework, then you will have much more industrial-type experience than most developers ten years older than you. The downside is that industrial-type experience, while it helps you make better decisions about large-scale software development, also tends to dull your brain. If you're already focusing on frameworks in college, you're going to be burned out and useless by the time you're thirty. You'll end up quitting and starting over from scratch in a new career, just to get away from software. Unless you're just one of those precociously responsible (*cough* boring *cough* *cough*) kids who tracked his gas mileage in high school and thought the coolest thing about the Science Fair was having an excuse to wear a suit and gesture at graphs.

      In college, you should be implementing your own language, becoming a whiz at Emacs Lisp, mucking with kernel modules, starting your own web business, building natural language parsers, and doing all the other silly, vain, perfectly useless (Emacs Lisp excluded) things that end up making you into a smart, versatile programmer.

    • by Llywelyn (531070) on Wednesday July 23, 2008 @02:35AM (#24299903) Homepage

      As a software development *student*, you should be focusing more on the concepts, on engineering problem solving, and on reasoning skills than on the specific technologies.

      As a software engineering professional, I learn the tools that I need to effectively do my job. I learn things that look interesting and applicable to whatever it is I am doing. Thus, I work with the GWT and with AJAX because I decided that's what I needed in order to tackle a problem we were having. As a senior engineer who is engaged in the hiring process, I care more about that you can think than that you happen to have seen and worked with twelve dozen technologies by the time you graduated. As a job posting I saw recently says [fogcreek.com]:

      We do not hire based on a specific list of buzzwords, technologies, or popular acronyms on your resume. Today we happen to use Wasabi, JavaScript, xhtml and CSS, and C++ to build FogBugz, but Python and .NET are likely to be important in the future. We use C++ and Objective C for Copilot. We have server systems in C# and legacy code in VBScript. Tomorrow we may be using something different. Whatever technologies, languages, or development environments you've been using, we expect you have mastered them in depth, and we expect that you will be able to master any technology, language, or development environment that we need in the future.

      You can't predict it and the specific tools will change tomorrow, so as a student I would generally say that learning it--unless it is for a specific project or class of projects, or because it contains a concept or problem solving idea that you want to learn--is a waste of time. I learned R back in school because it was more efficient than using Minitab for multivariate statistics and for statistical modeling, not because it was out there and I needed to put it on my resume. On the latter point, I still think learning Prolog and LISP were extremely valuable despite that I never use them professionally and will probably never use them professionally.

      Incidentally, if you are a good engineer, the language doesn't matter. If you are a bad engineer, the language still doesn't matter. *Problem solving* counts for more in the long run than bullet points.

      • by Gazzonyx (982402) on Wednesday July 23, 2008 @03:36AM (#24300231)
        Perhaps I didn't say what I was trying to say ;)
        What I was trying to get at is that, I've mostly mastered the concepts, and now I want to try everything that I can. Almost everything that I do is for the challenge/thrill of it. Yet, at the same time, I desire that what I hack around with should become a tool in my toolbox. It's almost like writing code that never gets used; it just feels wrong to pour your blood, sweat and tears in to a project that never gets used.

        I guess it's in my blood, my great grandfather was an architect on the Hoover Dam and Chrysler building, my grandfather a civil engineer (apparently, he used to slam trains together in White Sands, NM. with explosives on them to see how much shock would set them off), and my uncle owns a software company. It's like I have to find the biggest, baddest problem that I can, and then I must own it! And not just own it, but own it from three angles at once. Then, I put it down and almost never pick it up again unless someone asks me how I would attack that problem. I intern for a small local company where I maintain a Linux server, an old Access database, and write some bash scripts... and play with new 'shiny objects' when I've completely my assigned work. (my boss is a Comp. Sci. geek from back in the day - I can usually get him to let me geek out with stuff since he enjoys it as well, and on occasion, it's worked out well for the company) But when I get home, I want to build something! The more elaborate, the better!

        With SDKs, it's the same thing. I'm fairly sure that between kernel hacking and the release of java.util.concurrent with Java 6, (or maybe they extended it...) I failed a course or two. To be honest, while immature, I'd probably say it was worth it for the hours of fun it provided to fully grok the Java threading model or the interrupt routing for an SMP kernel during a critical section of code. The icing on the cake was when I got to hack around more the next semester while we were covering those topics. Or being able to speak somewhat intelligently on the use of 'goto' in class after reading about it in Code Complete. Sure, the extra pay off is nice, but it's what I would have been doing regardless.

        Maybe I'm sick, but I love programming languages. Last semester I was required to do a bit of LISP and PROLOG for AI class, ADA95 for procedural languages, and took up PERL for fun. They're all really fun to hack around in (except I can't really find a great use for PROLOG), and I'm always on the lookout for a chance to break out ADA again. Take it as you will, I also enjoy using recursion. It's too elegant to not admire.

        So, for mine own part, I've found that solving problems is relatively simple, just break it down in to atomic sub-problems, start with the most trivial, and divide and conquer each layer above it; if the solution makes sense, it works. I just want a few more hammers to try out on other problems. Unfortunately, mot problems dictate the most correct hammer by the time you've broken them down to isolated cases, and usually the most boring hammer is the one you should employ. :/
    • by Fuzuli (135489)

      No, you are not alone. This is a problem that almost everyone who develops software faces somehow. It all depends on your line of work actually. If you are working on building business oriented information systems which seem to cover everything from online gambling to financial decision support, you are in trouble, for there is simply too much technology that is competing in the field. In general, you have to have a decent level of knowledge and experience about major technologies, you can not avoid java or

  • by GWBasic (900357) <`slashdot' `at' `andrewrondeau.com'> on Wednesday July 23, 2008 @01:29AM (#24299601) Homepage

    My experience with GWT is rapid prototyping. Overall, I like playing around with GWT. It's a great way to quickly dynamic web sites without wading through the mess that JavaScript is. Considering that I do other kinds of software on a day-to-day basis; GWT has a learning curve that's gentle enough to allow me to write powerful UIs as a weekend project.

    GWT's integration with Eclipse; especially its debugger, is a significant advantage. Its compiler is also another advantage. I tend to shy away from JavaScript because I prefer compiled environments with rich debuggers.

    I think GWT's long-term strengths could be its maintainability, although someone who is experienced with both JavaScript and GWT will be better off making such a judgment. I have not written a large, multi-developer GWT application; thus I do not know what kind of complexities arise in such an environment.

    GWT has an odd deployment system that's designed to take advantage of HTTP caching. Compiled javascript files are named based on a hashing algorithm, thus a web server can be optimized to instruct the browser to only download code when a new version is compiled. This makes storage of compiled JavaScript difficult for some deployment scenarios, because the files always change.

    I've been reading the mailing list for about a year, and in general, it tends to have a lot of novices and hard-core Java developers. There's a lot of talk about using various Java frameworks within GWT. I get the impression that, even though GWT is Java-based, using frameworks like Spring or Hibernate is like ramming a square peg down a round hole.

    Some novices don't understand that GWT doesn't run under the JRE, or assume that GWT can somehow magically make their favorite library run in the browser. GWT compiles Java into JavaScript; it does not deal with Java bytecode (except in its debugger.)

    There's also a lot of talk about using various RPC / Remoting protocols when served from a Java web server. It seems that some Java programmers like that they can keep a simple layer between code running in the browser and code on the server. I personally avoid these layers and stick with simple AJAX calls into PHP or my custom-written C# server.

    I wrote this in GWT as a learning exercise: http://andrewrondeau.com/com.Memmexx.GearPod/GearPod.html [andrewrondeau.com]

    Now, you might think "wouldn't it be a cool idea to integrate an MP3 search engine into your demo?" I did, but it's locked behind closed doors because I don't want to get sued! (It turns out that the folks at Seeqpod got sued after I completed the version with the search engine.

  • Because most web developers don't know Java. They know XHTML, CSS and Javascript. Some know PHP. Most sure as hell don't understand how Java can be used to make a site and don't want to bother learning a whole new "language" (as it seems) to build one. So they dely on jQuery and Dojo which is pure Javascript that they understand.
  • If I remember correctly, this is the one where you write java and then it gets compiled into the javascript that runs in the browser, right? I'll admit that I'm biased against java, but still, even is this was my favourite language, the idea of generating javascript offline and then running it on the browser just sounds too complicated. I'd never feel like I could trust the generator.

    I'm not saying it'll never work, just that I think this is why nobody is rushing to adopt it (I do think it's completely unne

  • Not being used?? (Score:5, Interesting)

    by iwein (561027) on Wednesday July 23, 2008 @01:42AM (#24299675)
    I've been on a project using GWT in 2007, been quite successful. If you want to see an example that is public run over to Parlays.com, they have a Flex and a GWT version.

    If you want to write clean code check out my blog on TDD with GWT: http://is.gd/1156 [is.gd].

    With the 1.5 release they did some very promising improvements.

    So you're right if you say it is not mainstream, but to say nobody is using it is exaggerating. Just be patient, GWT will continue to grow.
  • We're going to be looking at it soon for an Intranet project, specifically ExtJS GWT. We'll see how it goes.

  • We are (Score:5, Interesting)

    by Arnold_DeVos (1331059) on Wednesday July 23, 2008 @01:57AM (#24299739)

    We have used it for a fairly big internal application for one of our clients. Given we wanted ajax rather than a typical rich client, the main advantage of GWT was that we could program in the same language end-to-end.

    We managed to avoid a lot of boilerplate code by using the same data class definitions (POJO's) in the server and client. So an object might be created by hibernate from a database record, copied to the client, displayed and edited, copied back to the server, manipulated there and finally updated in the database via hibernate.

    The main omission in GWT is a good framework for binding data to UI elements. Because there is no introspection available in the GWT client environment, it is hard to do this in a generic way. We solved the basic problem by generating class and property descriptors during the usual hibernate code generation step. We then created a UI-POJO binding framework that picks up and uses these descriptors. Again avoiding a lot of boilerplate.

    Our code for all this is here: http://code.google.com/p/gwt-hibernate/ [google.com]

    I'd say GWT worked out pretty well.

  • by DerekLyons (302214) <fairwater@nosPam.gmail.com> on Wednesday July 23, 2008 @02:06AM (#24299777) Homepage

    You start with the assumption it should be widespread, and are disappointed because it is not. Which leads to the question, what leads you to that assumption?

  • by SashaM (520334) <msasha&gmail,com> on Wednesday July 23, 2008 @02:44AM (#24299961) Homepage
    I've written quite a few GWT apps in the last year and a half. Here are two that I can show:
  • Here's my suggestion: look for a simple string that occurs in GWT pages but in few other places, then Google for it. That should answer your question.

  • Evernote [evernote.com] has a pretty slick web interface that is built with the Google Web Toolkit. I was positively surprised by its snappiness. Finding out it was GWT was sort of an "ah, but of course" experience.
  • by twasserman (878174) on Wednesday July 23, 2008 @04:15AM (#24300443)
    Ajax Patterns [http://ajaxpatterns.org/wiki/index.php?title=AJAXFrameworks] and eDevil [http://edevil.wordpress.com/2005/11/14/javascript-libraries-roundup/] compiled a list of more than 100 Ajax toolkits, covering a wide variety of underlying language technologies. While many of these get very little use, there are at least six [Yahoo UIL, Tibco (General Interface), Google GWT, OpenLaszlo, Microsoft .Net, and Dojo (or the commercial WaveMaker based on Dojo)] with a significant developer base.

    When people are looking for an Ajax toolkit, the Google name often gets it onto the selection "short list", but that doesn't automatically assure that it will be the final choice. Many corporate IT organizations insist upon commercial support for any software that goes into their business-critical applications. Of course, Google does not provide such support. In those situations, GTK will be ruled out for business reasons, independent of its technical merits. The net result is that there are numerous sites built on GTK, but the large variety of choices means that no single framework or toolkit has yet emerged as a favorite.

  • I used it (Score:5, Interesting)

    by Fuzuli (135489) on Wednesday July 23, 2008 @04:30AM (#24300511)

    Because I needed a website with a high level of interaction. The client asked for enabling disabling of various things on a widget, some bells and whistles,but nothing fancy. In the beginning I wrote the code for this using javascript, hand coded the whole thing. But change requests, and much more important than that, browser compatibility problems cost me a lot of time. GWT fixed this aspect. Mostly compatible with all major browsers, and being much more experienced in Java than in js, I became more productive.
    However, I should have limited my implementation to a single widget, and that was my mistake when using GWT. Use a plain jsp page, attach the widget to a div, and be done with it. Instead I've built the whole thing on GWT, and later fell in a position where I can not easily add very simple stuff. The usual GWT app is one single js chunk, which navigates to different pages by hiding and showing things on a page. This requires a little getting used to, and I've implemented more flexible things like pulling html via remote calls etc. But in general, mixing GWT with a more server side oriented technology (asp.net, jsp, jsf etc...) looks like a better approach now. But when you have to build a slightly complex interface where there are trees, enabled disable compoenents, users adding, removing things to a list etc, GWT serves well. I guess the secret is in the balance, just use it at the necessary level, no more. I could have used Flash, but that'd be a total pain for multiple reasons. (a lot of reasons actually)

  • by tangent3 (449222) on Wednesday July 23, 2008 @06:04AM (#24301169)

    Theoretically...

    Number of Java developers > Number of Flash developers > Number of Silverlight developers
    Number of Javascript capable browsers > Number of Flash enabled browsers > Number of Silverlight enabled browsers.

    Which is a good idea, since Google has created a framework in a language that most developers are familiar with, for a platform that just about all web browsers support out of the box.

    However...

    Number of PHP hosting sites > Number of ASP hosting sites > Number of Ruby hosting sites > Number of Tomcat hosting sites

    Which is probably one of the reasons why it's not doing so well.
    GWT-RPC is excellent. It allows me to use the same data objects on client and server, and debug both from the same IDE. But it requires a Tomcat server.

    Now if GWT is able to compile the server portion to easily deployable PHP code, this could lead to somewhere interesting.

  • by MrBlic (27241) on Wednesday July 23, 2008 @08:13AM (#24302181) Homepage

    I've recently spent a year with the GWT, and just a couple of months with Flex.

    I would use Flex to flashify whatever dynamic parts of a standard html page I needed to for my next project. Everything that I'm trying to do in GWT could be done much faster in Flex... and when you are done in Flex, you are really done.

    In the GWT, you have to be aware of what html each of the Java GWT widgets equates to... and then in the CSS, you have to work thinking about the resulting html. (FireBug makes it pretty easy.)

    Cons for GWT 1.4:

      - Long start-up times: web sites can take 8 seconds to show you their first page as the GWT javascript initializes.

      - One imperfect CSS declaration, and you're having to debug IE6 / IE7 / Firefox / Safrai issues... Only very plain sites are insulated well from browser incompatibilities.

      - Your site is all-or-nothing GWT. It's possible to use one GWT app to automate one part of a static page easily... but usually your whole site is 100% GWT, with no other static pages outside of the GWT's control.

      - The AJAX mechanism on RFC-compliant browsers only lets you make two async requests at once... a third request is queued until one of the first two async requests returns... making it only asynchronous to an extent.

      - I ended up having lots of html in my .java files, and using the HTMLPanel to turn that html into a GWT Widget. There are some parts of a web site that really do make more sense as HTML, and there's no easy way in GWT to keep the html separate (no templates!?!)

      - The integration of GWT development can be done simply, but it can also grow to mirror the complexity of EJB style Java junk way too easily.

      - IE needs special treatment (worth repeating.)

    That said, it's probably the best way to create a web app for an iPhone right now, since there's no flash on the iPhone. (Please Adobe, I'd love it if you created an Air run-time for the iPhone!)

    Pros of the GWT:

      - it makes it easy to handle the back button and bookmarks.

      - it can scale up to fairly large sites, and the smallest building blocks can be kept clean and small.

      - the end user experience is a good one after that start-up delay.

      - The GWT team has done lots of fantastic work, and in an open exchange... one of my coworkers has committed some changes to one of the supporting libraries.

    Flex, on the other hand is designed to appeal to people who are weary from fighting CSS / browser incompatibility issues. In Flex, you still use CSS, but it works the way you would expect all the time. In Flex, you can also skin any compononent to look however you want, and then have a very clean top-level which wires up the various components with their skins. It's really beautiful... and best of all, when you're done, You're done! You don't even have to test on IE6! The learning curve is about the same, or a little harder, but it's all forward motion.

    My next site is going to be 80% Django templates, with a good dose of mochikit (or dojo) for some dynamic parts, and a few Flex / flash applets sprinkled in where they make sense.

  • Internal project (Score:4, Interesting)

    by WPIDalamar (122110) on Wednesday July 23, 2008 @08:26AM (#24302329) Homepage

    We did a QA interface to one of our projects so we could test the backend without going through the rich client. It was a great experience and really easy to get working. The javascript/java backend communication was ultra-simple to get working.

    But...

    If we want to really easily create something that looks great we'll be sticking with more traditional approaches either using Flash/Flex or AJax with a standard JS library. Having a designer skin a GWT app is harder than those approaches.

    I've been reading a lot about DWR and that plus a UI library will probably give you most of the benefits of GWT. Have to give it a try soon.

  • No good widgets (Score:3, Interesting)

    by HalB (127906) on Wednesday July 23, 2008 @08:45AM (#24302483)

    It doesn't have any of the good widgets that exist on most of the google pages that make them great, at least the last time I looked. For instance, there's no pop-up calendar date picker like Google Calendar uses. There's no form field completion popup with scrollbar. So if you want to do anything good, you have to roll your own anyway, or use something like YUI.

    If you are going to end up using YUI anyway, it does everything GWT does and more, so you might as well simplify and limit your third party library complexity to one fewer library.

    Also, when something doesn't work in GWT, you usually end up debugging the javascript anyway. It's a lot easier to navigate code you wrote than generated code.

    It really doesn't buy you much over JS-only toolkits, IMHO. Unless all you know is Java and you want to make a very very simple website.

  • by not already in use (972294) on Wednesday July 23, 2008 @09:01AM (#24302699)
    GWT is cool once you get started, but eventually familiarity breeds contempt. The issues that always bothered me were the following:
    • Any UI toolkit is going to limit customization of the UI to an extent.
    • The javascript is generated from Java code on the client side, and best supports Java code on the server side. This presents two issues:
      • Good luck finding a cheap Java host
      • You are tempted to use cool things like Hibernate, which presents a problem when entities are being passed to what is ultimately javascript code.
    • Deploying was always a bitch
    • Writing a webapp in a statically typed language seemed.... wrong.

    I ultimately scrapped this project and started it over using another google product, Google App Engine. All client side stuff is done using jQuery, it gave me an excuse to learn python which I absolutely love. And, GAE has the specific goal of making it easy to deploy and scale the application, which was always something I had dreaded even thinking of.

1 1 was a race-horse, 2 2 was 1 2. When 1 1 1 1 race, 2 2 1 1 2.

Working...