The Google Web Toolkit

By Allen Holub

July 1, 2006 —

Regular readers of this column are familiar with my feelings about AJAX. I think of it as a necessary evil—the only politically (though not technically) viable way to get an interactive Web application’s rich user interface onto the browser. My main problem with AJAX is that once you get past the hype, AJAX is nothing more than a massive steaming heap of JavaScript, and I hate JavaScript. It’s a poorly designed language executing in a nonstandard environment with only the most primitive debugging support.

Most important, JavaScript is a fundamentally procedural language (the so-called object-oriented extensions are just warts). I just hate the idea of having to splice this garbage onto my well-designed object-oriented server-side application, and I hate spending the time required to get even simple things to work on all the most common browsers.

A few client-side AJAX libraries exist (Dojo, TIBCO’s GI, etc.), but if you use them, you’re still programming (and debugging) in JavaScript. The open-source libraries are typically undocumented, flaky and amateurish.

Google has gone a long way toward solving the problem by taking the make-it-look-like-a-nail approach to AJAX (an approach I normally don’t like, but it works really well here). I’m referring to the free Google Web Toolkit (GWT), available at code.google.com/webtoolkit.

The core of GWT is a compiler that translates standard Java to JavaScript.

You write the client side code entirely in Java, using a GWT widget library for the GUI. The system uses the familiar Composite design pattern (panels can contain other panels or widgets). Panels can be docked. Low-level widgets include various buttons (including check boxes, radio groups, etc.) text fields and areas (which can display HTML), hyperlinks, list boxes, a full-blown menu bar, tabbed windows, tables and trees. You can attach normal Java listeners to any of these for client-side event processing. You can easily customize look and feel.

Most of the classes in the java.lang package are also available on the client side, as are the java.util Date, Arrays, Collections and some of the basic collection classes (ArrayList, HashMap, HashSet, Stack, Vector and iterators across these classes). Other classes provide access to the DOM, cookies, browser-widow properties, and other client-side niceties.

For more advanced I/O, GWT supports a very clean client-to-server RPC system so that your client-side UI can delegate more complex operations to the server. You can also extend GWT via a “JavaScript Native Interface” (JSNI) that effectively lets you wrap a Java method signature around a JavaScript method, and provides mechanisms to call back and forth between Java and JavaScript.

Since you’re programming in standard Java, you can develop in whatever environment you like (Eclipse, etc.), and more to the point, the application will run (in “hosted mode”) as a standard Java application. The big-time benefit of hosted mode is that you can debug and test using your normal Java tool set (such as the JUnit and the Eclipse Debugger). A hosted-mode application is actually running in a browser simulator that integrates tightly with the JVM, but everything’s Java bytecode, so all your normal tools work. The browser emulator runs as an IE or Mozilla control. I’ve tried the emulator in Windows and Linux, and it works fine, but haven’t tried it on the Mac yet. Extension classes written with JSNI can run in hosted mode, so you have Java-debugging benefits with your GWT extensions as well.

Once you’ve gotten the application working on your development box, you then run the client-side code through the GWT compiler, which translates the Java to browser-independent JavaScript. You deploy by putting the generated files onto your server and adding a couple of simple tags into your HTML file. The GWT code interacts happily with foreign HTML and JavaScript, so you can mix it with hand-built code on a single page if you like.

The main drawback of GWT is that it’s still a work in progress. The widget set doesn’t support every bell and whistle you might like. (The main omission is drag-and-drop.) As is the case with all AJAX applications, your Web page will have to download a JavaScript runtime library (about 100Kbit, but it’s cacheable).

These omissions are quibbles, though. GWT is more than adequate for most applications, and it will save weeks of pain and suffering when compared with using JavaScript. I’ve tossed all the in-progress JavaScript in the application I’m currently building and have replaced it with GWT, and I’m quite happy with the result. I can’t recommend this system too highly.

Allen Holub is an architect, consultant and instructor in C/C++, Java and OO Design. Reach him at www.holub.com.

Share this link: http://www.sdtimes.com/link/29412

Google updates Web Toolkit to 2.0 The new release of Java application framework brings Chrome into the debugging and optimization picture

Google rocks the Web with browser release The latest product from Google is the Chrome browser, which has been created with a variety of open-source components, and can run plug-ins and tabs as isolated processes.

Zeichick’s Take: Google fights the good fight against old browsers By phasing out non-standards-compliant browsers, Google is pushing Web technology forward

Add comment

Name*
Email*
Country

Comment
Preview

News on Monday
more>>
SharePoint Tech Report
more>>

Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?

Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST