Sunday, June 03, 2007

Google Gears - Performance Out of the Box

Google Gears was released last week and it's been hugely exciting to get a look at this api, along with some of the apps people have come up with already.

Google Gears API

Obviously many of us had been looking at Adobe Apollo for awhile, and Google Gears is of the same mindset -- but even more encouraging it was released under the very liberal BSD license, which only adds encouragement to those of us excited about the rapid advancement of technology. It will be exciting to see the rapid progression of this 'platform' for offline integration of web applications. The community of web developers has so many ideas, and Google's release of Gears to the community in this manner will no doubt generate many ideas that will find their way into the next release of Gears is my only guess.

As an Ajax developer where I am particularly interested in Gears is in terms of performance, over and above online/offline synchronization as a feature. While the two go hand in hand synchronization has a specific place in many apps (internet connection dropped, queue-ing work completed offline, etc), I feel like the performance aspect of Gears with this offline database and client side file cache will become huge. I am looking forward to seeing many engineers benchmark their web applications once they have become enabled with and optimized for Gears.

Developing with Google Gears in mind, could become like Ajax has become the last two to three years. What I mean when I say that is that there are significant performance benefits that can be gained by limiting the number of trips to a server (both web and database), and processing items in batch. We have already seen this with regards to Ajax applications sending bits of data to the server rather than whole page requests, and this takes it a step further. We now have a larger set of boundaries to work with as web developers. We can choose how much to update, when to update, along with a client side failsafe. Having the cross operating system desktop intermediary is the enabler here, and the deployment potential of a large player like Google are obvious.

As Google continues its collaboration with Mozilla Firefox (I can't wait for Classes in Javacript 2.0 by the way!), and open source libraries like Dojo, it will become easier to integrate these offline caching and synch-ing paradigms into our development practices.

All of this enables richer, more responsive user experiences for the end user. It enables exciting new architectures for web applications. The future is surely bright for the paradigm of web-based applications growing in performance, capability and reach.

2 comments:

xeal said...

JavaScript with classes is no longer JavaScript. They'd better call it something else to make it less confusing.

Repeat after me 100 times: JavaScript is a prototype based language ;)

Mark Holton said...

Well, maybe they will name it "LiveScript", as I believe that is what Brendan Eich wanted to name it before the powers that be at Netscape had him change the name to something that sounded like Java ;).

I too like the way Javascript efficiently uses the prototype object to hold methods and other properties that should be shared by each instance. JS objects inherit properties and methods from their prototypes. Very efficient, indeed!