practice
Doi: 10.1145/1562164.1562181
Article development led by
queue.acm.org
The Google Web Toolkit is an end-run around
Web development obstacles.
BY BRuce JohNSoN
Reveling in
constraints
tHE wEB’s traJECtory toward interactivity, which
began with humble snippets of JavaScript used to
validate HTML forms, has really started to accelerate
of late. A new breed of Web applications is starting
to emerge that sports increasingly interactive user
interfaces based on direct manipulations of the
browser document object model (DoM) via ever-increasing amounts of JavaScript. Google Wave,
publicly demonstrated for the first time in May
2009 at the Google I/o Developer Conference in
San francisco, exemplifies this new style of Web
application. Instead of being implemented as a
sequence of individual HTML “pages” rendered
by the server, Wave might be described as a client/
server application in which the client is a browser
executing a JavaScript application, while the server
is “the cloud.”
The key browser technologies responsible for
enabling this new generation of Web applications
are not especially new: JavaScript runs within the
browser to manipulate the browser
DOM as a means for actually rendering
the UI and responding to user events;
CSS (cascading style sheets) are used
to control the visual style of the UI;
and the XHR (XmlHttpRequest) sub-system allows JavaScript application
code to communicate asynchronously
with a Web server without requiring a
full-page refresh, thus making incremental UI updates possible. There are
many more browser technologies that
read like alphabet soup: XML, VML,
SVG, JSON, XHTML, DTD … the list
goes on.
Curiously, these browser technologies have been available for many
years, yet it has taken until now for
mainstream developers to cobble
them together to create compellingly
interactive Web applications. Why?
The opinion of the Google Web Toolkit team—a perspective that can, of
course, be endlessly debated—is that
the primary obstacle is literally the
implementation details. It is simply
too difficult to code them all to work
together in a way that provides quick
and reliable performance on the wide
range of browsers available.
Our response was to design Google
Web Toolkit (GWT) to allow developers to spend most of their time writing and debugging application code
using the Java language rather than
JavaScript. Working in Java means developers can leverage the productivity
of Java IDEs (integrated development
environments). Once they are pleased
with their Java code, developers can
use GWT’s cross-compiler to convert
Java source code into functionally
equivalent, and optimized, JavaScript.
The idea of cross-compilation tends
to raise eyebrows, and we’ve heard
more than our fair share of incredulity
about this, so let’s take a step back to
describe how we decided on this approach—and how things have actually
worked out.
GWT began life as a prototype that
Google software engineer Joel Webber and I produced as a way to address
what might best be described as the