Code Luck

The idea behind the Google Web Toolkit is simple.

When building rich-n-thin clients using DHTML and AJAX, many people have noticed that Javascript standardization in browsers is--how shall we say it--piss-poor. Differences in event handling, divergent error handling, DOM quirks; it's a party. Throw in the fact that Javascript is loosely typed and you will soon start pulling your hair out by the handfuls.

The Google Web Toolkit offers this proposition: Write your AJAX apps in Java and then compile the code into Javascript. You get the benefits of programming in a strongly typed, true OO language and also some protection from browser quirks since they are abstracted out for you by the GWT.

Note that you can't use the entire set of Java libraries while coding a GWT app, of course. You can only use a subset that can be translated into Javascript. For example, it is crazy to use the threading classes and expect that to be translated into Javascript. But quite a few classes from the java.lang and java.util are available for you to use. Personally, I wasn't very impressed with this. For example, why can't I use the Drag and Drop Java API and have the resulting code translated into browser-agnostic Javascript? More and more AJAX apps are providing drag-n-drop support; it would have been nice to have this support in GWT.

Where GWT really shines is in the custom wrapper classes that are provided for you. The DOM has been completely abstracted out for you. So have events, cookies, timers, the top level browser window, the history list. A HTTPRequest object serves as an interface to the XMLHTTPRequest to make AJAX calls in a cross-browser way. There are classes for JSON parsing, XML parsing, and making RPC calls.

Also, the list of widgets provided is impressive: a Grid, a FlexTable (a dynamically growing/shrinking table), a Tree, a TabPanel, among others. It really beats coding these common UI elements in pure DHTML and Javascript.

What really speeds up the development cycle is that you can code up a storm in Java and then run your app in a "hosted" mode which is like a local Java runtime. If your application runs in hosted mode, it is guaranteed to run in "web" mode, which means it will run cross-browser. Once you have your code tweaked in hosted mode, it is a simple matter to run a compile shell script (provided by the GWT) to translate the Java to Javascript.

Shortcomings of GWT: Sometimes you have to get down and dirty with Javascript because the GWT doesn't quite manage to encapsulate everything for you behind a Java facade. A good example is lack of support for drag and drop. Or something like, say the Observer/Observable classes in Java--surely that could have been translated to Javascript. I know that pure Javascript libraries exist that implement the Observer pattern.

Personal opinion: I think GWT is here to stay, unless the next version of ECMAScript i.e. version 4, makes toolkits like the GWT philosophically redundant.

Note: I believe the Microsoft community has something similar to the GWT called Script# that uses C# as the front-end language instead of Java.