With all of the excitement around Google Developer Day, we didn't have a chance to tell you about a subtle point regarding the launch of the Google Mashup Editor: the editor's front-end was built using the Google Web Toolkit (GWT). Given that, we invited Rich Burdon, Tech Lead of the Google Mashup Editor team, to write a post detailing why they chose to develop using GWT. Here's Rich:

At Google Developer Day, we launched the Google Mashup Editor -- a quick way to build simple applications. The Mashup Editor lets you create mashups without having to do much coding; instead, you use standard HTML and extended tags, which correspond to UI controls that can display and manipulate RSS, Atom and GData feeds.

The product consists of three parts:

  • The Mashup Editor, which is itself an AJAX application.
  • A server-side hosting framework, which provides developer services (e.g., source code management via Google Code project hosting) and mashup services such as Google Base and a data store that can be accessed via feeds.
  • A JavaScript client library that implements the mashup UI controls and data processing functionality. The server-side components leverage Google's scalable infrastructure and provide access to Google services via the Google data APIs protocol; the client-side components were developed exclusively using the Google Web Toolkit.

Before starting the project, our team already had a lot of experience building complex AJAX applications by hand -- and had experienced many of the problems associated with this approach. Here are some of the reasons why we chose to use GWT rather than rolling our own native JavaScript framework this time around:

  1. Tools matter. As a veteran of the long-ago vi versus emacs debates, it's interesting to see the same enthusiasm go into the Eclipse vs. IntelliJ IDE arguments. Whichever side you're on (I fought for the latter in both cases, but we have members of both camps on our team), tools can make a huge difference in terms of developer productivity. You used to think twice before refactoring a large component that needed attention; having the tool take care of these kinds of complicated, repetitive (and error-prone) tasks makes life easier and can lead to better quality.
  2. OO is a good idea. I remember figuring out how to make JavaScript objects polymorphic and finally understanding what a closure is. Indeed, my colleague Stephan Meschkat, who works on the Maps API, often reminds me of JavaScript's inherent power and elegance. However, I like to have keywords like "interface," "private," and "final" at my disposal -- even better to have my compiler (and my editor) remind me that I'm attempting to call a function with inappropriate arguments. Type safety saves debugging time, and OO abstractions can help to reduce complexity in your code.
  3. Compatibility. Java's original slogan of "write once, run anywhere" fell victim to the intense competition between browser developers. Although JavaScript, being a smaller core language, has fared somewhat better, the complexities of juggling different DOM implementations over a growing number of browser platforms makes writing cross-platform AJAX components difficult. GWT's ability to insulate you from much of this complexity probably makes it a no-brainer for this benefit alone.
  4. The client is only half the story. Both the Mashup Editor and the resulting mashups themselves interact with Google services; being able to code both sides of a remote method call in the same language has some obvious benefits. Aside from the relative simplicity afforded by the GWT RPC mechanism, both client and server components can share constant definitions and in some cases, simple functions.
  5. Open systems are less scary. A programming framework is something that introduces abstractions. The benefits include making complex concepts simple and quicker to implement; the downside is that if you want to do something that the framework wasn't designed for, you're on your own. It was important for us to be able to get under the hood and tweak the native JavaScript. For example, the Mashup Editor's template-processing functionality uses a native JavaScript library that we borrowed from the Google Maps API.

Of course, the other huge benefit of open systems (and especially open source projects) is learning from the collective wisdom of everyone who uses the technology. And so we're looking forward to incorporating the ongoing developments of GWT within the Mashup Editor.

Interested in playing around with the Google Mashup Editor? Head over to its homepage to sign up for the limited beta, and then check out our mashup gallery and developer forum for sample mashups built by the community.