Showing posts with label IO2008. Show all posts
Showing posts with label IO2008. Show all posts

Friday, June 13, 2008

Google I/O Videos

The Google I/O 2008 sessions are now online. Included are slides and Youtube videos of a variety of topics, including Android, Open Social, GWT, Javascript and Maps. 

If you were unable to attend, I highly recommend the videos.  

Check out GWT extreme as an exciting example of the kinds of things you can do with JS and browsers:


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?

Wednesday, May 28, 2008

Google I/O

At Google I/O in San Francisco this week. A two day developer conference covering Google's public tools and APIs.


IMG_1236