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

Comments

To me,

[bucky0]

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:To me,

[VoyagerRadio]

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

Seems Too Heavy

[telbij]

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.

Not being used??

[iwein]

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.

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 are

[Arnold_DeVos]

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.

Re:The secret shame of Web 2.0

[try_anything]

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:Why are you expecting this?

[Kristoph]

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.

Re:fr0sty piss

[hostyle]

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.

I used it

[Fuzuli]

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)

GWT is a good concept

[tangent3]

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.

Re:Why are you expecting this?

[IamTheRealMike]

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.

Re: Accessibility :Why are you expecting this?

[HommeDeJava]

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)