My Impressions of Google Web Toolkit (GWT)

Posted on by

Recently I’ve been asked several times for my opinion on the Google Web Toolkit (GWT)  and I’ve given much the same response each time. Now, it’s easier to consolidate my thoughts and share them with everyone via my blog.  I want to preface this post by stating, as I always do, that I have not taken a “deep-dive” look at GWT and, due to my stance below, I haven’t seen a reason to do such research.  I also want to state up-front that I don’t believe there’s any inherent flaw in GWT that prevents me from using it; nor do I think it’s “bad technology.” Finally, I’ve done my best to not allow my general distaste for Java influence my opinion of GWT.

I do not believe that GWT offers a unique value proposition as a platform that establishes any advantage over other Web development platforms such as traditional HTML and CSS or Adobe Flex. Additionally, there are some clear areas in which GWT lags behind these counterparts.

GWT is a package that allows experienced Java developers to create rich Web user interfaces with little experience in Web development. It allows these engineers to use the Java language to build powerful, ajax-enabled interfaces with no knowledge of the building blocks of those interfaces (namely HTML and Javascript).  Taking a quick step back from the above thesis, I don’t want to downplay the power of such a tool; there are certainly many Java developers in the world who know nothing of web user interface development and who can benefit from GWT. However, I want to focus not on the usefulness for a certain set of developers (lest we begin a conversation about server-side javascript) but on the platform itself and whether it is at all a better choice for Web development.

A New Language?

As of version 2.0, GWT uses a declarative, XML-based syntax for loading UI controls (“widgets”) and the Java language to create bindings between widgets and other widgets—as well as widgets and data structures.  Developers using other UI platforms will recognize that this language pairing is the standard pattern for Web application development.  Adobe Flex uses MXML and ActionScript while traditional web development uses HTML and Javascript. All 3 of these options provide a declarative “markup” language paired with a programming language to add functionality. In addition, both GWT and Flex provide pre-built “widgets” that encapsulate some type of UI functionality. However, if we’re considering widget libraries part of the platform, HTML and Javascript have several libraries such as SproutCore and jQueryUI that provide similar widgets.  So here, there’s no clear advantage to any platform beyond what one can gain from incumbent subject matter expertise as discussed in the preceding paragraph.

Adobe introduced MXML and ActionScript3 as part of Flex to solve a very real problem: how to leverage the Adobe Flash player (and later Adobe AIR) as a full-fledged platform for developers. Between the Flash player and AIR, the platform has some distinct advantages over the Web such as a single runtime for multiple browser environments, the widest adoption as a video distribution platform, and the ability to deploy both Web and desktop applications from a single codebase. The use of a separate language is reasonable as, while your applications can be deployed to the Web, they are not leveraging the Web Platform.

GWT also brings its own language choices to the table (acknowledging of course that Java is used far beyond the scope of GWT). However, for Web UI development, Java is a non-standard choice at best. The stark difference between GWT and Flex is that a GWT application deploys directly to the Web platform meaning it doesn’t benefit from any of the advantages that a platform like Flash provides to Flex developers. GWT is simply a different set of tools to produce the same output.

Live Development on the Web is Great

Most Web developers have used tools such as Firebug or the Developer tools available in Webkit-based browsers. The ability to edit your code live in the deployment is simply awesome. Google understands this and has added an interactive development mode in the form of a browser plugin to GWT.  To describe this mode in a single word: clunky. It’s slow, it crashes, and in the demonstration I saw by a Google GWT team-member, it actually didn’t work period. I hope Google can work these bugs out; but from what I’ve seen it’s just not ready for prime-time.

Tightly Coupled UIs Feel Restrictive

From my observations, I also see GWT as encouraging tightly coupling the UI and application code much the way that JSF encourages such tight coupling. I personally don’t see that model as sustainable for long-term development which will need to deliver custom user interfaces on multiple platforms. I strongly believe that the future of application development lies in building powerful application services which rich clients can talk to in any number of formats: JSON, XML, AMF, RSS, etc. By leveraging this complete decoupling, development teams earn the freedom to choose the right tool for the job to build a kick-ass UI for each platform they want to support: maybe an Adobe AIR app for the desktop, an iPhone app, and a mobile Web UI built with with HTML and Javascript working through Django (simply examples; not endorsements).

GWT Has a Purpose

…but as a platform, it offers nothing that the Web doesn’t already offer through it’s own toolkit: HTML & Javascript. GWT exists to provide a gentle learning curve to Java developers who want to build Web applications but don’t know where to begin.  It’s a noble goal and a great tool for those people. Unfortunately, Java, like C and COBOL before it, is a language with many practitioners who believe they should only have to write a single language. For those people, I see GWT as a potentially dangerous crutch preventing them from learning something new and staying on the forefront of their field.  If you’re going to learn a declarative, XML-based syntax anyway, why not learn HTML5? And give Javascript a shot; you might just find you like dynamic languages!

  

  • Adam Brod

    Those are good points, Brian. I am also concerned that GWT is an abstraction that may not be worth the costs.

    I do think there are some advantages to GWT provides over direct HTML and Javascript – built-in cross-browser support, javascript optimization (mini-fy, removing unused code), compile time checking and type-safety (this is also a downside due to slowing down performance and limiting some of the cool prototypical features of JS). Also, it provides a nice way to avoid duplicating your model on the serverside (java pojos) and client-side (javascript objects). It appears to have very good unit testing that hooks easily into automated builds. Java tooling seems to be pretty far ahead of Javascript tooling when you look at refactoring, code analysis, etc. (Of course you might try to argue that javascript is so easy you don’t need a big heavy IDE.)

    Anyway, thanks for your analysis. I think you bring up a lot of good points about GWT and it is clearly not right for every project.

  • http://briancrescimanno.com Brian

    Thanks for the comment Adam; A few counterpoints:

    The cross-browser support is a function of the libraries shipped with GWT. As noted above, if you’re including the GWT libraries you need to include other libraries such as jQueryUI and SproutCore which also include cross-browser support.

    I think the issue of whether or not you’re duplicating your model on the client and on the server can go either way. Rather than fully duplicating the model on the client side, I’d rather be able to ask the server for a representation of the domain object POJOs that my client can understand (be it JSON, AMF, a POJO, whatever). It doesn’t need to understand the intricacies of the model; only the domain objects. Given the trend towards thicker clients, I personally see it as a fair tradeoff.

  • openmind

    Your comment regarding GWT is totally superficial. GWT is certainly beyond the purpose of allowing Java developers to code web application while avoiding HTML/CSS/JavaScript. Some deveopers opt to using the technology from a scalability perspective: scalable in terms of large size projects, performance and large teams. What is built into GWT is a well thought out set of organically aggregated Web technologies. As certain reviews on the net say, one cannot go too wrong and make stupid mistakes with GWT when developing Web apps of any size.

    GWT's Java binding is a bit outdated – it would have been better if it is a OO+functional language such as Scala, Groovy, Jython, JRuby or whatever JVM languages. How big a web project you have done with javascript? Why don't you try building an RIA-flavor enterprise application with hundreds of screens using HTML+javascript?

    Cappuccino, taking an Objective-J binding (modeled after the Objective-C language), along with other platforms, such as, Titanium/Appcelerator, Echo2 and ZK etc, all share more or less the similar GWT philosophy of introducing new declarative constructs/expressions (you may call it “new language”), though they differ from each other in “server-centric” vs. “client-centric” kind of approaches. These approaches all exist for a good reason. With your claim of doing everything using plain HTML+javascript, then these technologies are all just a waste of time and non-sense.

    It turns out, however, your posting is totally outdated, ignorant, without research ground and, non-sense, period.