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

Different attitudes to what immigrants bring with them

Marginally more interesting than usual (which is to say, ever so slightly interesting) post at language log: When two become four on the subject of attmepts to make English the official language of the United States.

On this question I find my feelings ambiguous. When I was young, and interested in everything, especially languages, I considered it a tragedy if someone who grew up in a second-generation immigrant household didn't speak their parents' mother tongue. What a loss! They would never have that as it were stereoscopic vision of things that even a rough and ready biligualism can bring. As someone who won a small proficiency with French the hard way, I thought people who had rejected, or otherwise been denied, the chance to be bilingual were the most pitiable kind of unfortunates.

Now that I'm getting old, and somewhat tired, I like to be able to understand what's being said to me without having to go to too much effort. In sum, I want it to be presented in my native tongue. The people I feel sorry for now are those who've lived all their lives in one place, and find that that one place has become a foreign country, no longer their home.

But enough about the deficiences of my twilight years. What I think is interesting is not just attitudes to the languages that immigrants bring with them, but the wide differences in attitudes to the different things that they bring with them. so for example, I'd characterise anglo-american attitudes broadly thus:

• Food: "Yum! More please!"
• Politics and/or religions: "Please keep it to yourselves."
• Languages: "Hmm. Not for me thank you."
• Money: "You can't use that stuff here."

It's the contrast between the first and the last one that's strongest. Most westerners like to try foreign food, and some cuisines get a really rapturous welcome. Nobody in the West, neither the general population nor the state itself, wants foreigners to try to pay for things in anything other than our own currency. Languages — somewhere in between.

Amateur Economists

Thanks to the Marginal Utility blog, I've found a new site for amateurs of economics at http://www.amateureconomists.com/.

Today my boxroom, tomorrow the world!

A very interesting and not too taxingly written article by two Microsoft researchers on usenix.org: Handling Flash Crowds from your Garage. Takes a look at things like Amazon and Google "compute cloud" services, and presents the authors' experiences with them, drawing some conclusions along the way.