Thoughts on OpenAjax

After a recent discussion on the jQuery mailing list where someone wondered if “jQuery was OpenAjax compliant” I decided to fully investigate the OpenAjax Alliance.

In the purest sense, the goal of the initiative is to smooth over the interoperability in between JavaScript code bases. Currently that means:

  • Keeping the global namespace clean.
  • Making sure libraries don’t overwrite each others window.onload events.
  • Keeping the global XML namespaces clean.
  • Keep any attempts to walk to the DOM from breaking.

This is good. Those are simple tasks that many libraries can easily get behind.

Granted, in jQuery we: Already have all our code in one global namespace, we don’t promote the use of window.onload, we don’t inject (or require) elements into our own XML namespace, and we don’t overwrite any of the browsers default methods. Effectively, jQuery’s entire OpenAjax implementation is just to defer the use of (the rarely used) $(window).load(…) to the OpenAjax Hub.

Reality is never as good as it seems, though, as I have some issues with both the alliance and the OpenAjax Hub implementation.

The OpenAjax Alliance is very, very, corporate. The alliance is populated by 66 companies and 2 open source projects (one is an open source project, backed by a non-profit foundation and the other is a by-product of university research).

Ok, that’s fine – it’s corporations wanting to set some standards. Obviously, however, it should be apparent that a number of, very popular, Open Source Ajax-capable JavaScript libraries should join the alliance, if not, at the very least, be consulted about the proposed specifications.

Let’s assume that they simply haven’t taken the initiative, as of yet. Ok, that’s fine – jQuery would like to join the alliance (to provide our input, hopefully steering them in a positive direction). How would this occur?

I’ve read through the OpenAjax Alliance Members Agreement [PDF] a number of times now, and even enlisted the help of my, more-legally-inclined, friends but came up short. You’re allowed to join if you meet the following criteria:

“Members” means the entities which have signed the Members Agreement and whose membership in the OpenAjax Alliance has been approved in accordance with Section 3.1

(emphasis mine) and some more relevant info:

Membership in the Alliance is intended to be broadly available to all organizations or individuals with a demonstrated interest and commitment to the Purpose, which is the development, enhancement, and promotion of programming technologies and techniques based on HTML-based browsers, Javascript, HTTP, or other specifications to provide robust and effective client Internet interactions, including the publication of Alliance roadmaps, Specifications, testing materials, and sample implementations that can be used to promote OpenAjax programming technologies and techniques.

I understand everything except for the “organizations or individuals” statement. jQuery (and Mochikit, Mootools, Prototype) are all popular JavaScript libraries that have no legal backing (Yahoo UI has Yahoo, Dojo has the Dojo Foundation). Unfortunately, since these JavaScript libraries have no legal backing (as a non-profit corporation, for example) they seem to be out of luck.

For more answers I turned to the OpenAjax member wiki which includes this helpful snippet:

Companies (including non-profit organizations such as open source projects) can join OpenAjax Alliance by following the instructions found on the public web site at: http://www.openajax.org/join.html.

On an exceptional basis, individuals can join OpenAjax Alliance, but only after they have an established track record of involvement and contribution to OpenAjax Alliance efforts and after recommendation by an existing Member. In these exceptional cases, the individual must follow the same procedure as companies (i.e., follow instructions at http://www.openajax.org/join.html). At this point, no individuals have been accepted as Members into OpenAjax Alliance.

There’s a couple points about these paragraphs that greatly amuse, and confuse, me. First, that only legal entities (e.g. corporations, non-profit corporations, or individuals) can join the alliance. Second, that all open source projects must be non-profit corporations. Third, that no individuals exist within the alliance (nor do they seem to be particularly enthused by the concept).

All of this really boils down to the fact that if I want jQuery to join the alliance (and I as its representative), the project would have to have some sort of legal backing in order to hold up. I can’t sign a document claiming specific ownership rights, or control, over something that doesn’t, legally, exist.

This is all (hopefully) an overreaction. But the very fact that no non-legally-backed entities exist in the alliance (and the fact that no good corporation would sign a legal agreement ambiguously defining the status of an “organization”) leads me to believe that many of today’s poplar JavaScript libraries are intended to be left out of the drafting of the OpenAjax requirements.

The implementation of the OpenAjax Hub (Source) is another issue at play here.

The Hub is meant to be this over-arching library that all other code bases plug into. It is, then, from this library that it delegates out to the necessary resources. Currently the basic implementation is 38.3kB uncompressed and about 7kB compressed.

A big issue that I have with the implementation is that it promotes the use of the window onload event as a means of knowing when the DOM is loaded and ready. A better solution has been available since June 2006. There is no reason to use window.onload to wait to do DOM traversal. (There are good reasons to wait for window.onload – but they mostly have to do with images loading.)

In the case of the Hub they make two critical mistakes: They force libraries to wait to do DOM traversing until after the full page has loaded (a deprecated, slow, and obtrusive technique) and they promote the use of vendor-specific event listeners over defined ones. For example:

var enclosedFunc = function(){ return funcOrName.apply(scope, arguments); };
if(window["attachEvent"]){
	window.attachEvent("on"+type, enclosedFunc);
} else if(window["addEventListener"]){
	window.addEventListener(type, enclosedFunc, false);
} else if(document["addEventListener"]){
	document.addEventListener(type, enclosedFunc, false);
}

A minor point about this piece of code is that it promotes the use of Internet Explorer’s attachEvent over the standard addEventListener. Additionally, all event object information is lost in the process (in IE) as the global event object is not passed to the original function. Both of which are frowned upon: The first because it’s not forward-looking to the day when browsers will support the W3C (or in Opera’s case, enforcing it’s use of IE’s specific methods), the second because there’s a serious loss of event information in the process that is not corrected.

The second, mis-guided, part of the Hub’s implementation is that of the “Markup Scanner”. The goal of the scanner is to, effectively, parse the document once and notify individual libraries when their corresponding markup appears. (For example, I could request to be notified whenever an element in a specific namespace appears in the document – or when an element with a specific attribute is available.)

Throwing standards to the wind, they struck out and decided to build their own selection standards for matching markup. Not only that, but their implementation is mind-bendingly slow. Here’s a small snippet from the scanner code:

var childNode, i = 0, childNodes = node.childNodes;
while(childNode = childNodes[i++]){
	if (childNode.nodeType!=1)
		continue;
	OpenAjax.scanNode(childNode);
}

I fear for the corporation who places this on their site, causing a horrible flash of un-JavaScript-enhanced content combined with a freezing-of-the-browser as the scanner attempts to traverse a 10,000 element page.

There are, at least, three very-fast implementations of JavaScript CSS Selector engines that are each capable of tearing through a document in a matter of milliseconds. I highly recommend that the alliance look to one of them to solve this matter.

What irks me the most about this Markup Scanner, and the whole OpenAjax Hub, is the fact that they’re deeming their code to be “the” code to standardize upon. In order for it to be a standard piece of code it must, at the very least, be:

  1. Free of bugs (and, by extension, easy to maintain).
  2. Mind-bendingly fast.
  3. Incredibly small.

Currently, the only requirement that the library meets is that it’s comparatively small (compressed). However, that’s 7kB of code that does nothing but make your library place nice with other libraries.

In my opinion, the OpenAjax hub could be reduced to a number of simple requirements:

  1. Use DOM event listeners in your code.
  2. Use a DOM Ready implementation to avoid using window.onload
  3. Use simple DOM queries to locate your pieces of markup (getElementsByTagName).
  4. Never overwrite any global variables.
  5. Keep your code confined to a single, global, namespace.

This would allow all libraries to live peacefully together, perform very quickly, and not require a single byte of overhead code. (Granted, if all libraries used a single DOM Ready implementation, perhaps that would be more cost-worthy.)

In short: The OpenAjax Alliance needs to seriously consider opening up their process to all Open Source JavaScript Libraries, helping to make their standards more practical and effective. Additionally, the OpenAjax Hub should be severely downsized, and reconsidered, if not removed entirely, as its addition serves little practical benefits (that a set of requirements couldn’t solve).

Update: I forgot to mention that a number of JavaScript notables, and jQuery users, have already chimed in on the “jQuery is OpenAjax Compliant” blog post. The post on this blog is a follow-up to that.

Posted: February 22nd, 2007

Subscribe for email updates

19 Comments (Show Comments)


Comments are closed.
Comments are automatically turned off two weeks after the original post. If you have a question concerning the content of this post, please feel free to contact me.

Secrets of the JavaScript Ninja

Secrets of the JS Ninja

Secret techniques of top JavaScript programmers. Published by Manning.

Subscribe for email updates

John Resig Twitter Updates

@jeresig / Mastodon

Infrequent, short, updates and links.