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?