Google's Innovative Yet Limited Ajax Environment: GWT
posted Sunday, 21 May 2006
Google's recent foray into delivering an Ajaxified Web application stack, the Google Web Toolkit, says much about Google's pragmatic method of delivering innovation to the market. I for one, would heartily recommend it for certain applications, while actively advising against it for others. One major issue is that Google makes a lot of assumptions in GWT that are non-starters for certain uses. Though making dramatic assumptions isn't a lot different than what Ruby on Rails does to make Web app development easy, the assumptions are different in interesting ways. Also note that Google does not provide a complete application stack with GWT; it only goes a little bit into the server, past the serialization boundary, which actually leaves the developer free to use the server-side frameworks and libraries of their choice, as long as their Java compatible. This is part of the pragmatism I was talking about and it turns out GWT is only high concept in a couple of places.
One of the reasons I track Ruby on Rails so closely is that it's an almost perfect match for the Web 2.0 way of building software: radical simplicity, support for almost instant turnaround of fixes and new features, automatic support for a public API so that applications are turned into platforms on their very own, and incorporation of well-recognized open source Ajax libraries, etc.. Note that GWT isn't even open source, though it is available today for commercial and non-commercial uses. As we shall see, GWT just does not seem as Web 2.0 friendly, and seems built for more traditional pure-play software as a service (Saas).
What's in GWT and Why Is It Special?
By now you probably think I don't think much of GWT, and if so, that's doing it a disservice. Rick Hightower recently did a wonderful job summarizing the key points of GWT, saying it was perhaps the biggest announcement at JavaOne, and so I won't repeat all his coverage here (indeed he just added a great interview with the GWT Product Manager, so please go read it.) GWT is free, seems very high quality, and lets developers write entire Ajax applications in Java, so they can take advantage of excellent development, testing, and refactoring tools such as Eclipse that have formed around the Java development world for a decade. Google claims that GWT results in Ajax software that is just as fast as hand-written Javascript, and it uses a lightweight servlet mechanism to provide data from the Web server. GWT even prevents that classic Ajax antipattern, breakage of the browser's back button. And of course, GWT masks the idiosyncracies of the different browsers from the developer almost completely.
But what makes GWT special is that it reclaims Ajax from the programming equivalent of the woodshed. Real developers have a strong aversion to Javascript, and for good reason. It's a twitchy, skittish scripting language that is made even harder to work with by different browsers processing Javascript in subtly different ways. Javascript was never intended for the design and maintenance of robust and sophisticated software applications. Just the sort of advanced in-browser software that we're seeing emerge almost constantly these days. The software development world has gone too far to accept such a remedial situation, and so with Ajax here to stay, workable alternatives to pure Javascript development like GWT are clearly desired. Ruby on Rails has done something similar with their Ruby to Javascript compiler for a little while now and GWT does the same thing for Java; getting developers back to tools and languages that were designed for the job of creating properly designed and engineered software.
Finally, GWT fully abstracts away the browser and leaves little directly contact available to the developer, though there are ways to break out and Google provides something they call the Javascript Native Interface (JSNI) to allow developers access to the local browser environment. Blendability with other Ajax toolkits and components is also a potential problem (though that is always an issue), and it's unclear as of this writing how easy GWT is to mix with Flash and Flex.
Potential Issues with GWT (or, does GWT create closed RPC Stovepipes?)
I did take a pretty close look under the covers at GWT this afternoon and there's quite a bit to like. The extreme thoughtfulness towards the developer's ease-of-use is evident, and there are several powerful ways to debug GWT applications including a neat plug-in for most platforms that allows sophisticated debugging, profiling, and analysis of GWT applications in the browser.
Despite this, there are some flies in the ointment, and the GWT designers made some choices that makes it hard for developers to take advantage of some of the most important aspects of Web development. One of these is their choice for using and exposing services. Surprisingly, developing GWT-friendly services will NOT create an open, interoperable Web service. In fact, GWT's servlet approach makes applications developed with it into walled gardens that can only communicate with other GWT services for their data. You have to separately develop the services you want to expose to the world as traditional Web services. This is in sharp contrast with other Web application stacks (yes, like RoR or ICEfaces) which can expose the same services to the world as the ones the Ajax applications uses. Using the same Web services as the application is offering to the world cuts server-side testing and development in half and also automatically creates a public, reusable API that lends itself to mashups and the many advantages to being in an service ecosystem on the Web. Hopefully, Google will address this in a future release of GWT because if true, that's a fairly serious limitation.
But this in itself isn't a showstopper for many uses, as are GWT's limited subset of the Java run-time library (only java.lang and some of java.util are supported currently). But one of the fundamental issues with GWT seems to be its inabilty to use services other than the ones developed using its servlet method. As far as I could determine, access to services other than those developed using GWT requires leaving GWT and using the Javascript native interface they provide, giving up many of the benefits of using GWT. Web service re-use is increasingly one of the most important aspects of Ajax development since the landscape of services avaialble on the Web has become truly amazing (see ProgrammableWeb's terrific directory of public Web services and APIs.).
Hopefully, the Java serializing scheme that GWT seems to prefer will be expanded to support a true Web-Oriented Architecture and non-GWT services such as RSS, REST, SOAP, and others. And it's this last piece, until properly addressed, leaves me to caution people considering GWT until it's clear how easy it will be for GWT to co-exist with SOAs, WOAs, and the rest of the Web. Because developing standalone, stovepiped software is a dying art form.
Good Write-Ups on the Google Web Toolkit
The Official Google Blog: Making Ajax Development Easier
Doug Schaefer: GWT Another Turning Point
Werner Schuster: Google's Plain Java Ajax Tools
Internet News: Google Cleans Ajax for Java
Richard MacManus: Google Web Toolkit Released
What do you think? Are you looking at using the Google Web Toolkit?links: del.icio.us
"Real developers have a strong aversion to Javascript"
