Friday, August 3rd, 2007
I sometimes get asked “why doesn’t Google eat it’s dogfood and use GWT”. I normally point them too:
- GWT has been out for just over a year (> 1 million downloads), so it is obvious that properties from 4 years ago may not be running GWT :)
- There are several parts of Google that do use GWT (such as Base)
- Just because we offer an open web toolkit doesn’t mean that it is the right tool for every web application out there.
We are starting to see more and more applications from Google make it out with a “powered by GWT” sticker. One high profile case is the new Google Mashup Editor which actually consists of three distinct 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.
Rich Burdon, of the Google Mashup Editor team, wrote about why GWT was chosen. Here is a closer look:
- 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.
- 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.
Posted by Dion Almaer at 8:59 am