Monday, June 02, 2008

Google I/O recap and summary

Well Google I/O is over. Hopefully there will be another one next year - the conference was great value, and had scores of smart people talking about interesting web things. I attended in part to learn about GWT. Initially I was very sceptical about the value proposition of GWT - compiling Java to JavaScript? Get real! Programming in a static language like Java? Two steps backwards!

Despite these disadvantages, I have come full circle and I now firmly believe that GWT is an excellent platform for advanced web apps. There are a few reasons why I now strongly believe this:
  • GWT has a form of late binding - allowing differing implementations for each browser platform.
  • GWT has good optimized support (in 1.5) for overlaying Java objects on to JSON objects, providing an elegant and efficient method of consuming JSON data.
  • Excellent and complex products are being produced in GWT, the kind I'd like to develop.
  • Good abstraction over browser quirks in a optimizing manner, as well as allowing for writing code in a abstract way.
Most of the benefits are not as a result of Java, but as a result of the Java to JavaScript method. By abstracting the non-portable aspects of JavaScript and resolving them at compile-time, you get run-time efficiency without losing your abstractions.

Most JS libraries that abstract browser differences do so by adding adapter layers, or annotating the built-in prototypes to create a new development approach. However, the practical realities of JavaScript performance don't encourage the use of extra function calls or closures. Using a Prototype example:

$('ul#myList li').each(function(li) {
// do something with each list element, possibly using a closed over variable
});

While elegant, this is not nearly as performant as more basic code:
var myList = document.getElementById('myList').getElementsByTagName('li');
for (var i = 0, il = myList.length; i < il ; i++) {
// do something with each list element, no closure necessary.
}

While in theory 'each' should know about the best way to loop over an array, you also incur the cost of two user function calls, and a closure. These are not free, even as they improve the code - mis-coding loops is a major cause of bugs.

Given that most JavaScript runtimes are interpreted (we are starting to see the rumbles of VMs for JavaScript), adding extra calls and object allocations is not free. Add these up and eventually the weight of your JS application will grind browsers to a halt.

While nothing is ultimately a panacea - better tools are always better. Increasing the level of your abstractions and letting the computer do the work for you is always better. It seems like JavaScript is becoming the new assembly language - and we all know how much demand there is for assembly language programmers these days.

If you found this useful, maybe my article on making CSS performant might interest you?

2 comments:

Anonymous said...

I would agree with you on almost anything you wrote, but creating complex user interfaces that look the same on Firefix and MSIE is a pain. Vertical and horizontal panels when combined together never align the way you want on all the browser, and the amount of widgets available for building the user interface is poor. We chose GWT 18 months ago and we are still working with it, but it's really hard to create good-looking GUIs. And the GWT compiler is deadly slow (it takes more that three minutes to compile an average GUI, and the new 1.5 version is even twice slower). We are really considering to switch to Adobe AIR.

Ryan said...

Hey Antonio,

Great feedback, thanks for the info.

Building great cross platform UIs is never easy, but it sounds like the flaw here is with the nature of DHTML itself, not anything GWT specific. You're indicating this by saying you're moving over to AIR - you get a more consistent rendering result at the cost of vendor lock-in.

Anyone else have some real to life stories of making hardcore production UIs work well on IE and FF using GWT?