GWT and GAE

One always looks, of course, for the ideal toolkit with which to develop AJAX-style web applications. It's a pastime into which one can put as little or as much effort as one desires, and it rarely seems to result in satisfaction. In that, it resembles the search for happiness... but I digress.

Some toolkits promise much and deliver little. Many seem focused on flashy effects rather than functionality. Most seem to have large and inexplicable gaps ("surely they must have realised they would need to..."). You end up combining, or trying to combine, different kits that are built on different principles and have no unifying structure, and whose subtle interactions lead to difficult bugs.

I'd more or less settled on YUI (The Yahoo! User Interface Library) as having the best functionality for my purposes. It's a bit heavy and a bit clunky, and new developments spend entirely too long in beta, but it's comprehensive and versatile, even powerful. I use it in the editing application for gedsguides.com.

Along the way, I'd had a look, along with everyone else, when Google brought out the Google Web Toolkit. An interesting approach: compile a Java source to a Javascript runtime (the delicious irony didn't go unnoticed — the Java you'd write using the GWT would once upon a time have run natively in a JApplet). The potential was obvious, as were the potential gotchas: differences between the development environment (a Java runtime) and the production environment (in-browser Javascript) might lead to severe debugging problems.

Happily, the quality of engineering that went into GWT seems to have been high enough for it to have garnered a good-sized community, so maybe the fears were overstated. There's even a version of Ext JS available for it, Ext GWT to give it a bit of extra pizzaz in the GUI. The combination seems excellent and I'm nerving myself up to rewriting a page of the GGW Admin Console with it, as a test.

Another area where GWT shows evidence of independent creativity is its approach to cross-browser compatibility. Most other toolkits, insofar as they attempt to solve this problem, approach it by abstracting it away the differences. The result is that they invariably have a base module that has to be loaded by the browser, and that translates their general code into browser specific calls, for whichever browsers are supported. This module needn't be very large, 10 to 20 kilobytes perhaps, but it does have to contain code paths for all supported browsers. And that's a reasonable price to pay for the independence it provides.

The reason all the Javascript toolkits have to adopt this approach is because they are entirely runtime, browser-based affairs. GWT offers the same browser independence to your code, but this is a pre compile-time affair! GWT then produces lots of different run-time support files for your app, one set of files for each browser (even, for each version of each browser). The end result is that the Javascript footprint of your application, when it actually runs in a particular browser, may be much smaller than with other toolkit: each browser has to load only the code that it needs. Extremely smart. The cost of course is that your server has to have room for tons of files; your application takes much more space on your server's disk than with the other approaches; there may also be an impact on your server's cacheing. These are all things that we know how to solve on the server though, and they play to its strengths; all in all, I rather like the balance that GWT has adopted.

Here's the Achilles heel. If your web application needs to contact the server for data (which, given that it's a web app, it's bound to do a lot of!), then the support that GWT provides for RPC on the server is implemented using Java servlets. This means that your server has to be Java based: Tomcat, or Resin, or JBoss or whatever. This is a matter of a particular implementation rather than anything essential of course, though there's a fair bit of work for anyone that wants to re-implement the server-side stuff using something like, say ... Python.

Why would anyone want to re-implement GWT's server side using something like, say ... Python?

Well say hello to Google App Engine! I remember getting very excited when this came out: "run your web applications on Google's infrastructure"! Who wouldn't want to do that? This would be instant death to the thousands of tiny ISPs who host millions of modest LAMP sites. The sort of stuff that uses a MySQL database for small amounts of data. Things like game guild sites with membership lists of a couple of hundred people, raid calendars, little bits of news and so on. (I still think it will impact these things severely, but over a much longer timescale than I first thought.)

The thing is that App Engine is Python-only. Lots of people have been wondering if it's possible to combine GWT, which is mostly a browser-client (AJAX) technology, with GAE, which is mostly a server techology. Trivially it is, since the pages you serve from your GAE web-app can contain anything of course, including GWT applications. But that only works with the most basic of applications. If you need to pass data between the AJAXy GWT application running in your browser and your server, then GWT wants to talk to a Java servlet. Or you could jettison GWT's preferred approach (RPC) and go for something RESTful (there's a JSON example app comes with the GWT SDK). In which case a Python back-end is as good as anything else; it's very doable, but there'd be somewhat more coding for you if you did that.

So Google need to adopt a more joined-up approach to web applications. They could commit to writing a GWT-compatible back end in Python and running on GAE. That's not such a bad idea; it migh even be the least work for them. Make it a compiler option, with a flag saying if its server code should be emitted in Java for Tomcat et al. or in in Python for (Django and) GAE.

Don't look for Protocol Buffers to help here though, even though it's touted as "Google's Data Interchange Format". Although Protocol Buffers already supports both Java and Python (that is to say, the supporting tools can emit code in both those languages) it's a binary wire protocol: suitable for slinging data around on an internal network, but not so good for (typically text-based) conversations between a browser and a web server, especially if there's a firewall in the way.

Update. Note that Google App Engine uses Protocol Buffers internally, to communicate between the application (i.e., your web app) and the App Engine server, and between the App Engine server and the BigTable servers (all internal to Google's private network see? — exactly the use case envisaged in the previous paragraph).