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?
How’s it work?
You can write you client-side code using the usual core Java classes in the
You 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.
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.
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.
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.