The Google Web Toolkit's AJAX Recipe: Less JavaScript, More Speed

The co-creator of the Google Web Toolkit (GWT) explains how his team plans to release a GWT version that compiles faster AJAX code than a JavaScript expert could write by hand.

by Glen Kunene, Senior Managing Editor

Dec 5, 2007

Page 1 of 2

an Francisco, CAHow popular is the Google Web Toolkit (GWT)? Google claims their Java web development framework for AJAX (asynchronous JavaScript and XML) applications has been downloaded millions of times since being launched during the JavaOne Conference in May 2006, but perhaps a better indication of its popularity is that Pearson Education dedicated an entire conference to it: Voices That Matter: Google Web Toolkit, a four-day affair for Java developers here this week. The 175 attendees exceeded Pearson expectations by 25.

In a media briefing at the conference, Google Engineering Manager and GWT co-creator Bruce Johnson explained the mission his team undertook when Google open sourced GWT under the Apache 2 license in December 2006: create a better user experience by enabling Java developers to create high-performance web applications using only the Java tools they know rather than trying to master the JavaScript skills that are necessary for creating responsive web interfaces for all the browsers out there. As Johnson describes it, the state of the typical web application today leaves a lot of room for improvement. "The average usability of web sites sucks," he said, citing all-too-familiar examples of web user headaches:

A mortgage application that requires the user to complete a 12-page application, but mandates "Don't Hit the Back Button" because the site's AJAX implementation breaks that functionif a user realizes he or she made a mistake on a previous page, the user is stuck.

An e-commerce site warning that a user's credit card will be charged twice if he or she presses the Submit button twice, yet the site just hangs while processing the initial submit click and offers no confirmation in the meantime

Of course, the 404 (page not found) and 500 (internal server) errors with which every web user is familiar

"These are implementation details that surface as usability problems," explained Johnson, adding that browsers are powerful enough to run the JavaScript code in the first two of the above examples correctly but Java developers with little or no JavaScript experience don't know how to implement it properly.

How do these complex JavaScript development requirement tasks fall to an inexperienced Java developer? Johnson offered an example. Suppose a product manager asks the development team in a "Web 1.0" Java shop (i.e., Java, JSP, Struts, etc.) to add a little JavaScript"just a couple of lines"to an application. When the team successfully implements that functionality and receives positive feedback from users, the sales team then considers their shop an "AJAX shop" and begins promising support for all users, resulting in "a landmine of compatibility problems for browsers," according to Johnson.

As Firefox, Safari, and even mobile device browsers begin to demand the same functionality that those couple of JavaScript lines provided, developers try to programmatically make their applications compatible by hand-coding the JavaScript and quickly find themselves out of their depth. In this scenario, said Johnson, the developers are caught between what's easy and maintainable for them (limited browser support) and what's best for the user's experience (cross-browser support).

GWT's goal is to free Java developers from having to make that choice by taking the client-side scripting out of their hands. GWT is composed of two components: an AJAX widget library and a cross-browser compiler that converts Java code into AJAX. Java developers can use each component independently if they choose to, but they don't have to write a single line of JavaScript code by hand.