Google Web Toolkit as Productivity Enhancer -- ADTmag

Google Web Toolkit as Productivity Enhancer

By Lee Thé
December 20, 2007

At the recent Google Web Toolkit (GWT) conference, a session on productivity showed attendees how to take advantage of GWT features such as reuse, user interface (UI) templating and code generation. The presenters knew what they were talking about. They were Bruce Johnson, tech lead of GWT, and Dan Peterson, GWT's product manager.

Three key points about GWT were noted in the talk. GWT is designed for user-focused Web application development. It helps you build AJAX (asynchronous JavaScript and XML) applications without headaches. Lastly, GWT leverages Java development tools.

Johnson and Peterson said Google's goals with GWT were to radically improve the Web experience for users by enabling developers to use existing Java tools to build no-compromise AJAX for any modern browser.

"Focus on the user and all else will follow" is their watchword, they said.

Looking Under GWT's Hood
Peterson described what's under the hood that makes GWT work. It mainly comprises a Java to JavaScript (JS) compiler, a hosted mode debugger, libraries for JRE (Java Runtime Environment) emulation and UI (user interface) widgets. GWT also includes support for standards such as RPC (Remote Procedure Calls for fetching server data), I18N (Internationalization), XML (eXtended Markup Language for bundling configuration settings) and JSON (JavaScript Object Notation for integrating GWT apps with other apps that use JSON).

Compiling to JS provides broad Web server and browser support. Debugging in hosted mode lets you use familiar Java debugging tools. Prebuilt Java widgets serve as cross-browser building blocks for applications.

Johnson then demo'd building a simple application in GWT. He showed how you want to debug against the real browser. It becomes particularly clear when you set a breakpoint. GWT can also show you the HTML rendered by a button -- especially useful for complex widgets. And when the GWT compiler is finished, there's no server-side dependency at all.

Getting a Grip on AJAX
Peterson described how developers get into AJAX trouble in "the AJAX slippery slope" scenario. Most organizations wind up becoming AJAX shops through a process that starts with your product manager coming in and saying, "We need some Web 2.0 features" (for Web-based communities and hosted services). You're a Web 1.0 shop but you provide the asked-for features. Everybody loves them; they say, "More!" Salesmen promise what you don't know how to build. Suddenly you're an AJAX shop.

Then the salespeople need you to port to something besides the Microsoft Internet Explorer (IE) browser, such as Firefox or Safari. The port turns out to be a huge uphill battle. You begin to hate all browsers, along with JS. The browsers sport widely different behaviors and present different compatibility issues when you're trying to port complex AJAX code across them all. You wind up entangled in spaghetti code, completely frustrated.

According to Peterson, "the Siren's call of AJAX cannot be resisted -- but it's easy to slip into making a poorly planned investment in AJAX, and you'll live with the consequences for a long time." But he said you can rescue your productivity by exploiting GWT's software engineering for AJAX.

GWT's Benefits
GWT offers the following productivity advantages for developers, according to Peterson:

It lets you use any Java integrated development environment (IDE), such as Eclipse.
It enables a rapid edit/test/debug/refactor cycle (refactoring cleans up code without changing its functionality).
It supports unit testing.
It supports code reuse through JAR (the Java archiving and compression tool) -- not via copy and paste.
It lets you take advantage of OO (object oriented) design patterns such as gang of 4 design patterns -- many of which need a strongly typed language (one which, like Java, predefines categories of data and then constrains what kinds of operations you can perform on them). JS doesn't support such patterns.
It uses Javadoc as a standard. This is a tool for generating API documentation in HTML format from Java source code.
It lets you deal with errors at compile time instead of runtime.

Productivity Is a Three-Legged Table
Johnson went beyond GWT's feature set in defining productivity. He compared productivity to a three-legged table, with the legs labeled as "functionality," "reliability" and "time to deliver." You need to provide all three elements to be productive. He warned that many developers mistake functionality for cool-looking UI elements or features that few actually use. Functionality means having capabilities that users actually need, provided in a form they can understand and operate.

Some Web application "features" are really anti-features, according to Johnson. He showed a graphical UI from a financial program that warned users not to use the browser's Back button, but only the Back and Continue buttons located on the form. The idea that you can't use the back button with AJAX applications is terrible, according to Johnson.

"You can't sacrifice that when you go to AJAX," he said. "We spent a lot of time working on this relatively unsexy aspect."

Johnson showed a warning on a Pay Online form that said "Please do not hit your "reload" button!...your credit card may be charged twice!" Forcing users to unlearn standard browser features and threatening to charge them 200 percent for something is a sure way to lose end users.

Then he showed a site that warned users they could only access the site with IE 6.0 at 800x600 resolution with Java enabled, or the Avant browser, but not Firefox, Netscape, or Opera. Johnson's comment: "These guys really aren't even trying."

Good Features Help Users
On the other hand, good features are user-relative and sometimes device-specific (as with mobile devices). The following list represents examples of good features to focus on:

Language, grammar, RTL (Run Time Libraries) and character sets.
Cultural norms for icons and colors.
Interaction aids, Input Method Editors or IMEs for inputting non-Western languages on conventional keyboards and screen readers for the visually impaired.
HW/OS (Mac, Windows, Linux).
RAM and CPU speed (+mobile).
Screen resolution (+mobile).
Network characteristics (dial-up, DSL, cable, satellite, cell). You may not know anyone with dial-up, but it could still be common with your end users. Also, satellite uses large packets, so chat is tough to do but big downloads are easy.
Tolerance for responsiveness, reliability and UI complexity.
Browsers (Firefox, IE, Safari, WebKit, +mobile).

Johnson demonstrated some of these features with demos of internationalization, of history and bookmarking support, and of RPCs. For example, the internationalization sample showed how you can provide for different number and date/time formats. He also showed how you can make an AJAX application load fast through clever use of the history mechanism. And with RPCs "we count milliseconds with everything we build." Finally, true to his philosophy of user-oriented functionality, he pointed out that he used no animation or special effects in anything he demo'd.

Crashiness Is Bad
Peterson moved the discussion on to the reliability leg. With a nod to the comic Stephen Colbert, he observed that "crashiness is bad," adding that inconsistent performance is also bad. Users prefer a program that performs the same way consistently versus a program that's sometimes faster, sometimes slower -- even if the average is the same. He added that when there is a problem, popup boxes need user-friendly messages, not programmer jargon such as "Warning: unresponsive script"

Of course, from Peterson's viewpoint, one of the best ways to improve Web application reliability is to use GWT, which helps build reliability five ways, he said:

You find errors at compile time, rather than at runtime (as with JS).
You can use other static analysis tools, such as FindBugs.
GWT integrates with the JUnit Java Unit testing framework and associated automated testing tools, using a special GWTTestCase base class.
GWT supports reuse, which lets you avoiding writing new bugs. For example, you can share entire components and applications via self-contained JAR files.
GWT's open source community provides you with a large-scale brain trust. Peterson claims that more than 10,000 developers are looking at GWT now, providing many more test cases than any one organization can go through. Plus the GWT team does all code reviews publicly. "There have been so many times when we were about to commit something and a developer would tell us about a bug we'd missed."

Moreover, GWT 1.5 will facilitate automated client testing with the open source tool Selenium. It can be used now but the GWT team is adding setDebugID() to the widget set so you can provide IDs for everything, and then write Selenium test cases against the Document Object Model (DOM) structure when you compile for testing. Then, when you compile for production, setdebugID() goes away itself.

GWT benchmarking takes place within the context of JUnit, Johnson said. For example, if they append a bunch to the end of an array list, they look for nonlinear responses in the performance of collections.

Only the Right Features Matter
Pressure to deliver the product can sabotage reliability, of course. Johnson recommends addressing this issue by focusing on user functionality. Only the right features matter; others can be dropped. And you figure those out by prototyping, testing on real users and repeating. Speed of iteration is key. "You'll learn so much more once you go live," he said.

But if you have to prototype early and often, the challenge is getting to prototypes you can test. Johnson said it helps to not sweat "JavaScript funkiness" early -- things like spelling bugs, speed and "null" versus "undefined" versus "false" versus "" (empty). Nor should you worry about cross-browser support and memory leaks. Most of all, avoid what he called "framework-itis."

Avoid Framework-itis
Johnson put it this way: Nice abstractions are for later. Yes, JS makes for difficulty in refactoring, which makes for maintenance worry, which makes for feeling the need to "get it right" from the beginning with a big fat framework. But you won't know what "it" is that you have to get right until you've done several iterations of user testing. So framework-itis is worse than wasteful. It creates bad inertia.

All of this prototyping provides a lot of residual value as well, Johnson added. User testing gives you lots of prototype code that you are going to try to reuse. And he says GWT gives you enough leverage to build real, working prototypes for usability testing. This reduces the distance between "mock" and "real." It also prevents hypothetical features users desire but which you can't actually implement. All in all, being able to refactor makes all of the difference.

Speed Delivery With a Rapid Edit/Debug Cycle
So instead of wheelspinning with framework-itis, GWT users reduce delivery time by a number of means. Time-saving approaches include: a rapid edit/debug cycle; the ability to leverage Java productivity tools; a large library of reliable code that's cross-browser from the start and designed to avoid memory leaks; and a growing library of open source libraries.

It also helps that you can share code between client and server, with Java source on both sides of the wire. Johnson says that actually, if you're careful, you can share source code that rightfully should be in both places (such as RPC domain classes and validation code). You can migrate logic from client to server without a total rewrite. You can also reuse existing JavaScript, calling back and forth from Java source to JS. The compiler doesn't know about each browser; it just picks libraries for targets.

For a Faster App, Just Recompile
Johnson promised that "as we make GWT better, you'll get the improvements just by recompiling." For example, one open source contributor made the ZIP 20 to 40 percent smaller.

A Q&A ended the session. One interchange got to the heart of the issue of productivity and GWT. The questioner asked whether GWT was more for traditional programmers or for ones coming from an HTML/JS viewpoint.

"It's for people who really want to be able to create great user experiences," Johnson said. "It's not really targeted at someone with a particular skill set, but with a particular attitude. We picked Java because it has a great type system and lots of user tools. But we don't care really."