Interview: Google's Bruce Johnson on the new GWT 1.1 Release

Version 1.1 of the Google Web Toolkit has just been released.  New features include:

• Automatic resource injection
  Modules can contain references to external JavaScript and CSS files, causing them to be automatically loaded when the module itself is loaded.
  
• gwt-servlet.jar
  Deploy this jar to add RPC to your servlet-based webapps without having to manually crack open gwt-user.jar to remove the servlet API classes.
  
• Javadoc-style API documentation
  As requested by developers
  
• An automatic mechanism to stop the browser from caching the .nocache.html file for your module.
  
• Localization
  Easily localize strings and formatted messages
  
• XML classes
  An XML library based on the W3C DOM
  
• JSON classes
  JSON has been made faster and moved into gwt-user.jar.
  
• FileUpload widget
  The much-requested file upload widget
  
• FormPanel widget
  Easily submit traditional HTML forms from GWT apps
  
• RPC optimizations
  Speed improvements and a more compact wire format
  
• JUnit enhancements
  Unit tests are much, much faster than in 1.0.21. You can now test asynchronous things like RPCs and time
  

InfoQ sat down with GWT Tech Lead Bruce Johnson to discuss the new release. He indicated that they were very excited at the number of developers who have subscribed to the GWT Google Group (over 3500) and downloaded the developer SDK. In response to why the GWT approach of compiling Java into Javascript was favored versus providing a pure Javascript library Bruce responded:

The primary motivation was the number of great Java development tools. Capabilities like context-sensitive code completion and global refactoring are vital to keeping your code base healthy during rapid development. And then there are tons of other mature Java-centric tools you get to use with GWT, like JUnit, Clover, JProfiler, Javadoc, FindBugs, Maven, and lots more.

In terms of the two languages, JavaScript is very flexible, which is a real strength for rapid development. That same flexibility can become a liability as your project becomes larger, requiring more engineers to work on a shared code base. For example, there are a variety of ways to implement OO concepts in JavaScript, each having different memory, speed, and maintainability tradeoffs. In big JavaScript code bases, you can end up spending as much time fiddling with the mechanics of the JavaScript code style as you do on the application logic itself. Java doesn't have this issue; classes and interfaces are well-defined concepts that just work.

In regard to why Google didn't take the route of leveraging pure Java on the client and promoting wider distribution of the Java Plugin and Java Webstart instead:

We wanted to enable developers today. At the moment, JavaScript/DHTML seems to be the one "platform" common to all browsers.

Bruce indicated that the new localization support in the 1.1 release is interesting, because under the hood it leverages some of GWT's more advanced code-generation facilities. It allows you to define large numbers of localized messages, but only the ones you actually use in your application get compiled. This keeps you application very lean. He also meantioned that GWT's automatic dead-stripping of unused code is an example of why it's a genuine benefit to have a compiler in the mix versus a handwritten JS library.

When you write JS libraries by hand, maintainability (e.g. comments and descriptive identifiers) and minimizing script size can be somewhat conflicting goals.

Another key feature in the new release is simplified JUnit integration that allows the ability to unit test asynchronous RPC calls in both hosted mode and web mode. The one major feature desired by developers but not included in 1.1 is hosted OS X support. Bruce indicated that he's forced himself to use OS X in order to feel developers pain and be a daily reminder to implement it as soon as the schedule allows.

The conversation then switched gears to talk about the various GWT widgets that have sprouted up since the initial release:

[I like the fact] that there are a lot of them and that they are actually easy to create and reuse. I also get a kick out of seeing GWT libraries that interoperate with great JavaScript libraries like scriptaculous using GWT's JavaScript Native Interface (JSNI). We never wanted anyone to view GWT as mutually exclusive with JavaScript, which is why we introduced JSNI...you can decide which code you want to write in Java and which code you want to write in JS, then easily stitch them together.

The conversation finished by discussing the possibility of open sourcing the GWT Javascript compiler so developers using GWT could provide bug fixes and enhancements:

We've talked about that possibility from the beginning, so yes. Open-sourcing the tools right now could be more of a distraction than a help. It wouldn't serve GWT users if we took our eye off the ball by starting lots of discussions about the plumbing of GWT when we want to be focusing on making GWT the best it can be for developers. We'll periodically revisit the question as GWT evolves a bit more.