Just wanted to post a quick update to the ongoing discussion on where things currently stand with LABjs and the breaking changes in Mozilla and Webkit trunks precipitated by some incomplete wording in W3C spec.
A really long thread on W3C public-html list has been brewing over the past few weeks regarding the fact that the W3C spec does not adequately provide a way for web authors to handle the use-case of parallel-load/execute-in-order, which is important for dynamic script loaders (like LABjs).
Other options
A variety of different view points and alternative ways to address the issue have been thrown around. Some of the people on the list feel that this use case is not important to solve because authors can just concat all their scripts together. This is obviously short-sighted given many previous discussions that demonstrate the performance benefits of parallel loading and independent caching.
Other members on this list feel the best way to handle the use-case is to create some sort of API for authors to directly do the “preloading” trick. This trick essentially relies on loading all scripts in parallel into the cache but not executing them (using several possible tricks), and then once they’re all in cache, re-requesting them with proper <script> nodes to immediately pull them from cache and execute them.
The fact that LABjs invented this trick (using the fake mime-type <script type=’script/cache’>) for IE, Webkit, and Chrome browsers does not mean I think it’s the best way — in fact, it’s an ugly and error-prone approach to the use-case, and I always hoped I could eventually deprecate that once the spec reflected a better solution.
One major gotcha to “preloading” is that if any resource in the “preloading” queue doesn’t send out proper caching headers, not only will that resource end up being requested twice, but the assumption of immediate execution from cache will fail and thus dependencies will be in a race condition. Some estimates have suggested that as much as 70% of all script resources on the web are served without proper caching headers — a scary number in its own right, but also quite illustrative of the pitfall to this technique.
So, the part of the crowd that thinks the solution lies in <link rel=prefetch>, or `new Image().src=…`, or Stoyan Stefanov’s <object> preloading technique, or… those options are all, in my opinion, missing the bigger picture of how “preloading” can really fall over for this use-case if caching is not correct. Moreover, they are all more complicated to implement, which makes script loaders like LABjs more complicated than they should have to be.
The Proposal
So, Henri (from Mozilla) and I have been discussing a simple proposal to amend the W3C spec to cover the use case in a straightforward way that avoids such clumsiness and pitfalls.
In a nutshell, the idea is to extend the spec so that the `async` property is present and its value (true/false) is respected, both for <script> tags in the HMTL markup and for script-elements that are injected dynamically (currently, the spec says nothing about `async` for injected elements). If an author (like the LABjs tool) wanted to inject scripts to have them load in parallel, but have their order preserved, they could simply set `async=false`. If the author instead wanted the “execute as soon as possible” behavior because there were no dependencies in the queue of loading scripts, they could set `async=true`.
Ultimately, this actually makes the spec more consistent and symmetrical, given that we’re making `async` work pretty much the same for injected script elements as it already does for markup <script tags.
This proposal idea is still forming, but that’s the main idea. Several people on the list have suggested support for the idea. Others however are not in favor of it, and they are the main voices suggesting myriad other more complex solutions (like a `document.executeScripts` API, for instance).
So, the discussion definitely needs to continue and find some consensus. Then, we need to advocate for W3C to adopt it, and then we need to really rally to get all the browsers (especially Webkit and IE) to agree to implement the spec. All of that needs to happen before the next major release of Webkit or FF, or LABjs is going to basically fail.
As you can see, we’re far from out of the woods yet. I call on you the community to help join the effort. The more people we can get behind a proposal, the more of a chance that something might happen before the inevitable bulldozer of “progress” demolishes what LABjs tried to build.
Next Steps
Because the aforementioned email thread is now quite long and complicated to digest, I am going to be moving the discussion over to a simple Wiki page in WHATWG. I encourage you to try and read some of the recent (dozen or so, probably) messages on that email thread to get up to speed, and then join the effort in continuing the discussion toward consensus over on the Wiki. I will post an update here as soon as that page is up.
Update
Here’s the Wiki page on WHATWG to continue the discussion.
