The Google Web Toolkit - Software Development Times On The Web

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.

EMAIL THIS ARTICLE

SEND FEEDBACK

MORE COLUMNS

SUBSCRIBE TODAY!

E-Newsletters:
  News on Mon/Thurs.
  Test & QA Report
  EclipseSource

SUBMIT

JOB BOARD

PDF & PRINT EDITION

* Requires Resource Account! LOGIN or SIGN UP

* Download Current Issue!
ISSUE 8/15/2008 PDF

* Need Back Issues?
DOWNLOAD HERE

Receive The Print Edition?
SUBSCRIBE HERE

EVENTS CALENDAR

Business of Software 2008
9/3/2008 to 9/4/2008
Boston
Red Gate Software

VSLive New York
9/7/2008 to 9/10/2008
New York City
1105 Media

Interop New York
9/15/2008 to 9/19/2008
New York
TechWeb

VMworld 2008
9/15/2008 to 9/18/2008
Las Vegas
VMware

Mobile Business Expo
9/16/2008 to 9/19/2008
New York City
TechWeb

MORE EVENTS

GET NOTIFIED!
About all of the latest Resources

SD TIMES 100

6th Annual SD Times 100

It's time once again to
recognize the organizations
or individuals that have
demonstrated leadership in
their markets.

HOME SITE MAP RSS CURRENT ISSUE BACK ISSUES SUBSCRIBER SERVICES ABOUT US CONTACT US BZ MEDIA