Categories


Archives


Recent Posts


Categories


The Two Futures for Javascript Libraries

astorm

Frustrated by Magento? Then you’ll love Commerce Bug, the must have debugging extension for anyone using Magento. Whether you’re just starting out or you’re a seasoned pro, Commerce Bug will save you and your team hours everyday. Grab a copy and start working with Magento instead of against it.

No Frills Magento Layout is the only Magento front end book you'll ever need. Get your copy today!

AJAX, Web 2.0, etc. etc. Five or six years ago programming Javascript user interfaces on the web meant a lot of tedious DOM debugging in IE, Netscape, early Mozilla builds, and (if you were awesome and/or a masochist), Opera.

Javascript libraries like Prototype, jQuery, and YUI made a lot of that irrelevant. They became hugely popular because they provided consistent (more or less) access to DOM manipulation, event handling, AJAX requests, and some form of higher level programming abstraction, (OOP, Builder Pattern, etc.)

This allowed developers to stop thinking about the best way to solve the browser problem, and concentrate on their problem.

Prototype and jQuery were geared, in a large part, to the existing pool of web developers. Their primary purpose was to provide a bedrock that you could build anything on top of, be it a multimedia presentation, animation, or user interface widget.

YUI was something slightly different. There certainly were aspects of existing web development methodology in its design, but at the same time the overall philosophy seemed to be “How can we bring the existing concepts of software UI design to to the web”.

That was then, and this is now. It’s 2009 and the economy is going through horrible gyrations. This always brings a shift in the way we approach technology.

The Future

There’s a lot of hardcore, smarter than you, Computer Science going into Javascript engines. Google Chrome has v8, Mozilla has Trace Monkey, and Safari has SquirrelFish.

All of these projects dramatically increase the speed of Javascript, The Language. Going forward, any Javascript library that wants to stick around is going to leverage those performance increases. I already see that starting, in at least two different ways.

First, we’re going to see libraries attempt to outpace browser developers and provide features that web developers have been clamoring for or were simply thought of as not-possible. Things like Sizzle, a CSS selector engine implemented in pure-Javascript that’s library independent.

Second, we’re going to see a battle for which UI library will become the dominant way to provide a desktop application like experience via the web browser. YUI started this trend, and you can already see an arms race heating up with jQuery UI and the sort-of-fork to YUI, Ext JS. The big shift here is the original wave of libraries were about providing access to the DOM to build whatever UI Widgets you wanted. The next wave is going to be about providing an already completed set of robust UI Widgets so you can concentrate on your application logic.

All very exciting stuff, with two caveats.

Bogey Men

What’s unclear is what sort of role Internet Explorer is going to play in this next wave of library development. IE is part of a larger corporation, where it plays a particular strategic role that has kept it out of the Javascript performance wars. Various forms of IE still make up 70% to 80% of the market, and any Javascript library that fails to recognize this will have a hard time gaining wide acceptance outside of its niche.

Beyond IE, there’s also the question of which parts of in-browser Javascript will see the biggest performance increases. It’s a well accepted truism that DOM operations consume the lions share of resources in an AJAX application, but none of the various projects directly address this. It’s quite possible one library may provide a better UI experience or more robust API, but if DOM performance is weak they leave the door open for someone else to eat their lunch.

All this makes me believe we’re headed toward a continued balkanization of the web as an application platform, with a possible widespread return to the “You must use Browser X” days of the first dot com boom. It’s never been easy to create cross-browser applications, but we may be headed to a place where it’s simply not feasible.

All that said, the developer that knows the ins and outs of the various browsers and can both work around quirks or avoid them in the first place is going to be well situated.

Ending on an Awe Inspiring Note

One project I’ve failed to mention so far is the mind boggling Cappuccino, which combines both approaches I’ve already mentioned.

First, it extends Javascript to create a new language (a strict-superset of Javascript) called Objective J. This can be used in any browser that supports plain old Javascript.

Secondly, using Apple’s Cocoa as a model, they’ve created a rich, object oriented UI framework that completely (leaks aside) abstract the DOM out of the picture.

The next two or three years are going to be remarkably chaotic as the various Javascript frameworks battle it out between themselves while the big-name runtime environments like Adobe Air and Silverlight attempt to shift how we think about web applications. It’s unclear who, if anyone, is going to come out on top, but it’s certainly an interesting time to be a web developer.

Originally published January 4, 2009