Friday, August 3rd, 2007

Google Mashup Editor powered by GWT

Category: Google, GWT

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.
  • 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.

Rich Burdon, of the Google Mashup Editor team, wrote about why GWT was chosen. Here is a closer look:

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.

Posted by Dion Almaer at 8:59 am

3.6 rating from 32 votes


Comments feed TrackBack URI

Very cool post about given requirements and how an expert dev came to his set of decisions………………….. I have had this discussion with my friends of the Java ilk. Here are my two cents: Java is not optimized/ best suited for every task. (hard to convince me it’s as well suited to web development as Rails is for a large class of web apps) I understand Google’s motivation for sticking with a finite number of platforms/languages, makes great sense for their business, maintainability across the enterprise, etc… likewise understand the motivation of the mashup dev here (very cool, btw), and he makes a lot of great points given his requirements (efficiency seemingly being a main point, not going outside the Java bounds, using his familiar IDE, etc) so it makes sense for him. In general though, for optimizing Ajax development, I think it’s a best practice to understand the language and write straight JavaScript on the client. …………………to that end, hopefully improved and lighter weight IDE’s will start to bubble up that are optimized for Ajax development.

Comment by Mark Holton — August 3, 2007

Very interesting post.
Don know why but i preferes Dojo over GWT.


Comment by sudhir — August 5, 2007

Great post to start with. But, what I miss is an option to get a beta login to the Google Mashup Editor. Can anyone help me out to get a login.

Comment by Lovegin — August 7, 2007

I love it.
How is it that google is so wonderful?

Comment by how to setup — September 4, 2007

Nice man.
I think I saw something similar ona yahoo blog the other day

Comment by refluxamine — September 5, 2007

Leave a comment

You must be logged in to post a comment.