Slashdot Mirror


Is Anyone Using the Google Web Toolkit?

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?"

4 of 470 comments (clear)

  1. Re:To me, by VoyagerRadio · · Score: 5, Interesting

    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).

    --
    Harold
  2. We are by Arnold_DeVos · · Score: 5, Interesting

    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/

    I'd say GWT worked out pretty well.

  3. Re:fr0sty piss by hostyle · · Score: 5, Interesting

    Apart from a few niche Web 2.0 sites, most websites are still built using tried and tested backend tech, and laid out using HTML, CSS and some graphics. GWT is pretty much doing everything using Javascript and a little bit on the server side serving xml/json. Not everyone needs AJAX. Most sites need to be able to work without it (for accessibility, backwards cinpatibility and non-javascript visitors), so unless its capable of adding really useful features (cases of which are few and far between) AJAX and GWT are just not necessary. Its nice if you can have it, but its a luxury you don't actually require for a usable website / web application.

    --
    Caesar si viveret, ad remum dareris.
  4. Re:Why are you expecting this? by IamTheRealMike · · Score: 5, Interesting

    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. 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.