We’re seeing a lot of move recently – Mozilla pushes their JavaScript API, Webkit adds CSS coolness, Opera comes up with Canvas 3D and Internet Explorer with awesome new events like recently featured hashchange. Now even Google comes up with their own browser and Gears is therefore becoming a own standard for that very own browser.

If you look at all that development however, it’s becoming very clear that it’s NOT the same than 10 years ago. I believe the overall idea behind it is different: Browser vendors are not actively trying to lure people to exclusively use their browser, but they’re trying to push the standards for the first time in 10 years – they want to push the web .

As a web developer, one might think it’s all a big mess now, and it does help nothing to their very own situation, because they cannot use the new standards of one browser in their new product – what about the other 75% of their target audience? And then, I’m not even sure if that feature survives in 2009!

Here is the point where I come in, as a JavaScript library developer. What we library developers can do is smoothen the path for these poor web devs. There are two ways of doing so:

1. The Copy approach: Replicate an existing standard on other platform with the help of JavaScript
2. The “Lowest common multiple” approach: Take a couple of different standards across browsers and create a subset that can be used across browsers

Let me show you one example for each approach to better show you pros and cons:

1. The Copy approach: Google’s excanvas
   excanvas tries to bring the <canvas> element to Internet Explorer by using VML. While I think it’s a great project, it has some fundamental flaws: excanvas is not able to replicate the whole canvas API using VML. Although they’ve done a fair job of porting most of the features, some are missing simply because it’s not possible/too slow/too much work to port them.This makes developing for it fairly difficult, because you never now exactly what behaves how.
2. The “Lowest common multiple” approach: Dojox GFX
   The Graphics engine of Dojo creates a own API and uses several different standards to render the exact same result. The advantage here is pretty clear: By defining what to support and what not in a limited subset, a web developer can be sure that whatever he uses here, even the most awesome, cutting-edge features, will work on every platform.

In my personal option, the second approach is the one that helps defining new standards. It’s the library developer in the end that reviews all standards and tries out what’s possible and what’s not, and therefore, the library developers opinion weights a lot. The library developers are the ones that have the power to bring new features to web devs as early as possible – not the browser vendors.

Cheers!
Paul

(What I talked about in this post is something i will feature again in my session for the Ajax Experience. If you have a change, I invite to check it out!)