Andrew Cherry - The Cherry Pit ... 'cuz life's like a bowl of cherries?

Richard Burton, Tech Lead of the Google Mashup Editor Team talked about the choice to use GWT:
The Article on the GWT Blogspot

So looks like my own opinions of GWT are sort of reinforced by Burton's discussion. When I first started looking into GWT, actually looking for something to use for a course project in my Software Engineering class , I immediately took to it given the project requirements to have strong implementation of OO methods, JUnit testing and Design Patterns. Given that GWT takes the web situation and converges it on one stable, mature language (JAVA!!). Our project ended up being a success and raise a few eyebrows here and there when people saw what we were able to accomplish.

My original posting about some of my experiences with GWT can be found here

From Richard Burton's article:
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.