First Look: Google Web Toolkit

Portions of this entry were first published in the SitePoint Tech Times #139.

Have you written your own AJAX framework yet? It seems all the big boys are doing it. Microsoft is bringing us Atlas for ASP.NET, Yahoo!’s User Interface Library is open source, server agnostic and beautifully documented and Adobe is working on Spry, which is off to a shaky start in the web standards department. Do we really need another?

Google’s late-but-inevitable entry into this arena is certainly no copycat. The Google Web Toolkit (GWT) is nothing less than a completely original approach to web development that allows server-side Java developers to take their skills to the JavaScript domain… without having to write any JavaScript.

In short, you write, test and debug your client-side code in Java and then use a specialized compiler to convert it all into cross-browser JavaScript for use on your site.

How’s it work?

You can write you client-side code using the usual core Java classes in the java.lang and java.util packages, as well as a nice library of classes that come with GWT that let you access the same browser features that are available in JavaScript (the Docment Object Model, alert boxes, setTimeout, XMLHttpRequest, etc.).

GWT Menu Bar WidgetYou also get a bunch of Java classes for adding widgets to the page, from simple buttons to complex drop-down menus and trees. All of these widgets offer events that you can subscribe listener objects to, and write Java code to respond to them.

When you’re ready to test out your application in a browser, you simply compile your classes in your Java IDE of choice and launch the GWT Shell, which pops up a specialized browser window and loads your application. On Windows, that browser window uses the Internet Explorer rendering engine, whereas on Linux it uses Mozilla.

The GWT Shell acts as a go-between between your Java classes and the special browser window, allowing your application’s client-side logic to run within the browser even though it is implemented in Java, not JavaScript. This small miracle actually lets you test and debug your client-side logic as you would any other Java code! Set breakpoints to pause and step through client-side event handlers, write unit tests to verify that your user interface works as designed. It all just works.

At this stage, your application is still a collection Java classes, and the final development step is to compile those classes down to efficient cross-browser JavaScript code. The compiler that comes with GWT actually reads the source code of your classes and generates the equivalent JavaScript code!

You can then take the generated JavaScript code, along with your static HTML, CSS and image files and dump them on a server as you would for any other web site. The resulting code is entirely self-contained—no browser plugins or special server technology required.

What about AJAX?

As I mentioned, the class library does give you access to the XMLHttpRequest object normally used in AJAX applications, but GWT also offers an even slicker method of communicating with the server.

In addition to your client-side code, you can write Java server-side code. Because it doesn’t get converted to JavaScript, this code can use the full capabilities of the Java platform, and any additional class libraries you may require.

In your client-side code, you can set up classes that are able to communicate with your server-side code. When your application is compiled, GWT will automatically generate all the JavaScript needed to communicate with the server on the client-side, and will compile your server-side code to a set of Java Servlets.

You can deploy these Servlets on any Java web server, and let GWT do the rest. GWT manages the conversion between JavaScript variables on the client-side and Java objects on the server side, and again it all just works.

GWT also includes a full browser history management system, allowing you to involve the browser’s Back and Forward buttons in your application’s navigation, even though the browser never actually leaves the page containing your applications.

Sticking Points

Google has definitely put together an impressive platform with GWT, but as one would expect (especially from a beta product) it’s not perfect:

  • GWT detects and supports browsers by their user agent string.

    You must rely on Google to add support for future browsers. Right now, for example, GWT applications are incompatible with IE7. You can hack the toolkit to treat it like IE6, but that’s the extent of what you can do to support new browsers.

  • The bundled GWT widgets make extensive use of tables for layout.

    If you want you application to generate a standards-compliant document structure, you’ll need to write your own widgets, which isn’t a happy prospect.

  • GWT was written to work with Java 1.4 or later.

    As such, it does not take advantage of Java 5 features like annotations and generics. This adds some redundancy and bulk to the code you must write, especially when working with the AJAX features of the library. For example, each server-side access point in your application requires you to write an interface to describe the servce, another interface to describe the asynchronous version of the service, and finally a class to implement the service. Using annotations, you could do it all by writing just one class.

  • The development shell does not support Mac OS X.

    Google is saying that Mac support is planned, but for now GWT development is limited to Windows and Linux. Compiled GWT applications run just fine in Mac browsers, of course.

  • Unclear best practices for security and performance.

    By masking the client-server division, GWT could lead unwary developers to make some serious security and performance blunders. You really need to know what you’re doing to use GWT effectively.

But the biggest thing lacking in GWT is an example of a finished, real-world application running in the wild. No doubt Google is hard at work on its next big project using GWT, but for now at least GWT is unproven technology.

This article provided by