Open Source Ajax Framework For Java EE Application Developers

ICEfaces RIA Journal

Subscribe to ICEfaces RIA Journal: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get ICEfaces RIA Journal: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


ICEfaces Authors: Ted Goddard, Steve Maryka, Pat Romanski, Ken Fyten, Shay Shmeltzer

Related Topics: RIA Developer's Journal, ICEfaces RIA Journal

RIA & Ajax: Article

Google's Innovative Yet Limited AJAX Environment: GWT

Google's recent foray into delivering an Ajaxified Web application stack says much about Google's pragmatic method of delivery

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 the 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?

More Stories By RIA News Desk

Ever since Google popularized a smarter, more responsive and interactive Web experience by using AJAX (Asynchronous JavaScript + XML) for its Google Maps & Gmail applications, SYS-CON's RIA News Desk has been covering every aspect of Rich Internet Applications and those creating and deploying them. If you have breaking RIA news, please send it to RIA@sys-con.com to share your product and company news coverage with AJAXWorld readers.

Comments (8) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Steven Barkdull 10/17/07 07:25:21 AM EDT

Are you serious? The author says:

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

1. Real Programmers? Real programmers are capable of mastering whatever tools are required to get the job done.

2. Twitchy and skitish? I have never heard a programming language characterized as "twitchy and skitish". In fact, I am not even sure what those terms mean in the context of a programming language.

3. Who have you been talking to that has the background to make the assertion regarding what Javascript was intended for, and how is that even relevent? For years software developers have been successfully extending technologies for purposes beyond the scope of the technology's original intent.

Enterprise Web 2.0 07/16/06 03:37:53 PM EDT

Trackback Added: Riding the hockey stick: Scaling Web 2.0 software; With all the talk last week about MySpace becoming the #1 most visited site on the Web, there's also been a lot of talk about how Web 2.0 sites like MySpace handle their sharp growth rates. Because Web 2.0 sites explicitly leverage network effects, wh...

Anil Sharma 06/01/06 04:39:43 PM EDT

My friends insisted that I give my reasons why do I think Java to Java Script is not such a good idea. I guess it is a fair demand. Without getting into the details of the specific product (GWT), here is a list of my reasons:

1. There are many open questions - what packages of Java can I use, will collection classes map onto JavaScript code, can I use Java timer, can I use Java multi-threading?

2. How primitive types are handled?

3. If the generated code is not optimal, can I change it? (remember all the pains of changing generated code in any code generation model)

4. If I have to change the code generation template, is it worth it? "I can change it" - it is not a valid argument. It often requires heavy duty work to change and mantain it.

5. Can I avoid learning HTML DOM? If yes, then what is the UI model? Do I have to learn it?

6. Java provides compile time checking. But I may need a dynamic programming model (which is good for UI. There is always some display only information that you need to handle without worrying too much about its data-type).

7. Is it proven for a production application?

8. Can you really escape JavaScript if you have chosen AJAX as the technology? Or, do you really want to escape. Very soon you will need to know JavaScript say, to improve performance.

9. I find development cycle (code change, execute, test) is very efficient for an interpretive language.

10. If we had a good JavaScript debugger, would we be thinking about Java to JavaScript. If not then, is it not an interim arrangement?

Anil Sharma 05/31/06 06:23:54 PM EDT

I like to be a contrarian and call it a brain dead idea. We need a JavaScript debugger and not a Java to JavaScript compiler. It is all about DOM and not so much about JavaScript. It will be a nightmare to debug if Java to JavaScript has one wrong mapping.

It is a radical idea though.

I tip my hat if gmail and google map were really written using Java to JavaScript way.

Phil Haigh 05/26/06 05:06:16 AM EDT

"Surprisingly, developing GWT-friendly services will NOT create an open, interoperable Web service"

I'm sorry but I don't see this as a problem. The GWT is targeted at building rich-functionality user interfaces in the browser, so the server-side interface to support the dynamic nature of the application will by its nature be tightly coupled to the precise requirements of the widgets it is supporting. Those widgets can and will change, and so will the server-side interface with them, even if the underlying business process does not.

It is logical to share business services but the server-side interface of an Ajax-enabled browser application is not a set of business services but a set of internal user interface support services. Don't confuse the two!

AJAX News Desk 05/22/06 08:23:28 AM EDT

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.

SYS-CON Australia News Desk 05/22/06 08:17:40 AM EDT

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.

AJAX News Desk 05/22/06 07:38:28 AM EDT

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.