The last song on the radio, as I was parking my car today, was Turning Japanese (bonus points if you can name the artist without using Google). This is not the ideal song to have running through your head on a workday, or pretty much any other time. So in an effort to dispel the demons of eighties novelty pop music from my tortured brain, I thought today was as good a time as any to write about the Google Web Toolkit (GWT).
GWT is a framework for writing AJAX interactive web applications. Take a look at the GWT home page for lots of great information about GWT. I'm going to look at this from the point of view of answering the key question - "Why GWT"? In other words, out of all the AJAX frameworks out there, what compelling reasons are there to choose GWT?
GWT has its own mechanism for remote procedure calls between the browser and the server. This works a lot like vanilla Java RMI - define interfaces and implementations for your server functions, and code will be generated to allow your client code to call them as if they were simple local methods. This blows away all the work of defining XML or JSON data formats for requests and responses. Just code the function for the server, call the function (still in Java) from the client code, and all of the marshalling, unmarshalling, network communication, etc. is done for you.
GWT also supports other RPC methods, such as XML or JSON over HTTP. You can write server code as standard SOAP or REST web services and GWT will be able to use them directly. This will take longer to code than the GWT RPC mechanism, but allows you to use legacy web services or services intended to also be used by non-GWT clients. A good middle-ground approach may be to prototype using GWT RPC, and re-implement as web services later.
Download sizes are kept even smaller by a unique GWT feature, namely...
Writing code that works on any browser is great. But there is a cost - the framework has to include code for every browser. You may be viewing the page in IE, but you also downloaded code specific to Firefox, Safari, and Opera, which will never be executed. Deferred binding is the GWT solution to this dilemma.
There is also provision for taking advantage of caching. The bootstrap file is intended to never be cached (and is helpfully suffixed with "nocache.js" as a reminder). The implementation scripts are intended to be cached, and have file names that are a hash code of their contents. This means that if you re-compile, but there are no changes in a particular file, it will have the same name and will allow the browser to use the already cached version. If the file changes, it's filename will change and therefore force a reload when it is next requested. All of this is done without any developer help (the generated bootstrap script deals with the filenames automatically). Pretty neat, huh?
I've only talked about deferring binding based on browser type so far, but this is a general mechanism and you can define other context-dependent variances as well. The most common use of this is...
Localizing a GWT application is very straightforward and very similar to how it is done in standard Java applications. In the simple case, just create properties files with locale suffixes, access them by key through a GWT interface, and the locale-specific string will be used. The cool part is that GWT uses the deferred binding mechanism to make sure that only those properties for the current user's locale are ever downloaded.
As with browser-specific code, this starts at compile time. For each combination of browser AND locale, an application script is generated. So, if you have, say, 4 browsers and 3 different locales, you will have 12 files generated - such as FireFox in English, FireFox in French, IE in English, etc. The bootstrap file will examine the client environment and load the application file specific to the detected browser and locale.
It should be obvious by now that the Google team put a lot of effort into ensuring the highest possible performance. Image bundles are yet another performance-boosting feature of GWT. Defining an image bundle allows the GWT compiler to package a number of images into a single file which is accessed through a Java object. This reduces the number of network round trips by getting all images for your application in a single file download. The packaging is done by the GWT compiler; all the developer has to do is define an annotated interface with a function to access each image.
Some frameworks work best only if they are in charge of the whole page. GWT "plays well with others", in that it can generate entire pages or elements within a page equally well. The GWT scripts work by creating HTML elements inside a specified element on a page during the onLoad() event. To embed a GWT application in an existing page, you therefore only need to include the script file and add an id to the element you want to contain the application (which can be a div, a td, the body, anything). Couldn't be easier.
Now, if I could just get that song out of my head...
GWT's x-platform promise is rather like Java's. It mostly works, but not always.
If your application is heavy, I don't think it's such a good idea to use GWT.
@Johann - It's true that GWT is not inherently optimized for mobile applications. Some people have reported success using it for iPhone and Android development, although it seems like it would take some tweeking and documentation is lacking.
It's super hard to test the UI using JUnit. So while GWT supports JUnit, it doesn't mean _that_ much.
A proof of concept is always recommended when you evaluate technologies such as GWT. Here are some of my observations:
Nice article and good points. I've pointed a number of my co-workers that still haven't seen the GWT light!
Nice introductory article! What I find is still missing on GWT is easy and nice validation of input data. So I made my own GWT Validation Library. You can check it out under: http://techblog.maydu.eu/?p=7
i think google should limit products to all browsers except IE
Great article! Regarding Localization why does GWT need to use separate bundles per browser? Shouldn't that be abstracted by GWT somehow? I think it is overkill.
All good reasons, however I'd like to add that GWT doesn't work well on mobile devices. If you plan to support these (or you have to thanks to scope creep), GWT isn't optimal.
KeyLimeTie is a full-service design, development & digital strategy agency, helping clients communicate more effectively and intimately with their customers through interactive marketing channels.
Specializing in web and mobile application development across a variety of platforms, KeyLimeTie provides content management, ecommerce, and custom application solutions, while also assisting customers with social media campaign and reputation management.