WHATWG Wiki - User contributions [en]

Talk:Dynamic Script Execution Order

2011-01-03T15:05:46Z

Serverherder: /* response */

Please discuss the proposal here. All informal feedback is welcomed, and when it's appropriate, please add content to the main page.

== What about CommonJS / RequireJS? ==

I'm not sure we need to complicate the HTML or browser engines in order to satisfy the advanced use cases. To me it seems that the JavaScript langauge itself could abstract the requirements and let the browser vendors implement whatever solution they see fit. Specifically, if JavaScript provided the define() and require() calls proposed in the CommonJS "specifications" (and implemented by [http://requirejs.org/docs/api.html RequireJS], [http://svn.dojotoolkit.org/src/dojo/trunk/_base/_loader/loader.js dojo (trunk)], and others *Yabble?), then browsers could just load and evaluate scripts as fast as possible without regard to script execution order.

This would solve all of the problems except for the current inability to use loaders like LABjs in FF4 or webkit. To solve that problem, we should consider keeping the existing functionality or triggering the deprecated functionality when needed.

--[[User:Unscriptable|Unscriptable]] 01:29, 2 November 2010 (UTC)

=== Response ===

This is a valid point except that it assumes that all code that needs to be loaded is "modular"... in fact, most code on the internet that needs to be loaded is NOT modular, and instead requires particular ordering when being loaded... for instance, "jquery" and "jquery-ui" -- jQuery must be run before jQuery-UI is loaded and run.

The spirit of this proposal is to add the facility to native browser (rendering engine, specifically) behavior, such that any and all existing content is able to be loaded (even with dependencies and order) without modification.
<blockquote style=background-color:#eee>
Are we trying to codify how one would implement this HTML dynamically so I can achieve parallel loading but retain dependency that is inferred in the order?

<blockquote style="background-color: white">
<script src="jquery.js"> </script> <br/>
<script src="jquery-ui.js"> </script>
</blockquote>

If so, we must consider the case in which the dependency itself loads additional code which the discussions around `async=false` or even text/cache do not account for.
[[User:Serverherder|Serverherder]] 19:23, 15 December 2010 (UTC)
</blockquote>

=== Dependent code should be modular ===

I completely agree, 99% of JavaScript in use today is NOT modular, but that's arguably because there was no built-in support to make it modular (IMHO, YMMV, RTFM, BBQ, ROFL). But that doesn't mean there aren't dependencies that span script files / script nodes. I don't know how many sites would be broken (or if there is any way to determine how many sites would be broken) if/when the latest browsers started loading and evaluating script-injected scripts out of order. It's not just LABjs-based sites. I'll bet many dojo and YUI sites will break, too (although I don't know this for a fact because I don't know exactly how their dynamic script loaders work).

'''''In any case, breaking existing sites is a BAD IDEA. :) There should be some way to allow LABjs and other dynamic script loaders to continue to work.'''''

The part I don't agree with in the proposals is that it should be the job of HTML and/or the browser engine to manage dependencies. Specifically, I am talking about the scriptGroup element and the "waitFor" attribute. The "async" attribute may be the right level: it appropriates only general heuristics to the browser: ''load these scripts whenever you like, but load these other scripts in this order''.

Detailed dependency management belongs in the modules, though. This is how it's done in most environments / languages: import statements, include statements, etc. It's no different in JavaScript, if a developer wants to take advantage of some code in another module, she/he should import it into their current module. This should be the model moving forward. It's not hard, it's not un-web-like, and it's already being done.

Existing code can be made to work modularly, too:

1. Identify modules and wrap them with a define() method.
2. Identify dependencies using either the [http://wiki.commonjs.org/wiki/Modules/AsynchronousDefinition Asynchronous Module Definition] format or the CommonJS synchronous format

async format:
<pre lang="javascript">
define(['dependency1', 'dependency2'], function (dependency1, dependency2) {
/* this is the factory function, return the module inside here */
return { /* some object, but could also be a constructor or a function */ };
});
</pre>
sync format:
<pre lang="javascript">
define(function (require, exports, module) {
/* this is the factory function, require dependencies and return the module inside here */
var dependency1 = require('dependency1');
var dependency2 = require('dependency2');
return { /* some object, but could also be a constructor or a function */ };
});
</pre>
In the async case, the browser may employ whatever method it sees fit (e.g. parallel) to download the dependencies since the code inside the factory function won't execute until all of the dependencies are loaded and evaluated. In the sync case, the browser has no choice but to download and evaluate the dependency before continuing code execution. It's conceivable that the browser could find and asynchronously pre-fetch the inline require()'ed dependencies in the sync case. (RequireJS doesn't quite do this. Instead I believe it finds the inline require() calls and converts the module to an async module.)

'''''So, in short: don't break LABjs (or any other script loaders), but don't extend the spec to manage dependency management from HTML.'''''

--[[User:Unscriptable|Unscriptable]] 01:29, 2 November 2010 (UTC)

== Response #2 ==

The cat's already out of the bag... we've got a dozen+ years worth, hundreds of millions of javascript files out there, which are NOT modular, and will not be modified to be modular.

If we're talking about either trying to change all the JS on the web to be modular, or trying to extend the HTML markup spec to include a better facility for accomodating the existing script content, I think the former is idealistic and "correct" but the latter is realistic and "right".

A modular loading system will only work for modular code, but a general loading mechanism in HTML (like the <script> tag) can load both modular and non-modular code, which is why that more general mechanism is what's in HTML right now and not some more specialized loading API that only loads a small percentage of JavaScript code out there.

The <script> tag has worked fine forever, and there's been no real big push to do away with it in favor of having all loading handled by JavaScript -- in fact, that would be impossible because if you had no way to load JS onto the page with a <script> tag, then no JavaScript could run on a page to load more code. So I don't agree that we should stop adding functionality to the HTML loading mechanism and only focus on JavaScript.

If we agree that the <script> tag itself is not only required but normative, then I'm not sure why decorating the <script> tag with additional behavior to help it be more powerful is a bad pattern. We've addded "defer" and "async" already. I'm not sure I understand why adding a wrapper tag called "scriptGroup" would be that much different than attributes on the <script> tag?

I also don't think that "scriptGroup" constitutes "dependency management". "scriptGroup" is a semantic way for a web author to express that they want to group a set of scripts together ONLY so far as execution order behavior is concerned. It implies nothing more to it (that "dependency management" would imply) than that.

For instance, consider this: if JavaScript had been built with non-global context and statement level context and sandboxing and such things, we'd have a much more secure JavaScript right now. But just because JavaScript may someday be taught some new tricks in terms of security, that doesn't mean that "now" HTML shouldn't try to help solve the problem. If for instance the <frag> tag can be used to create a sandboxed environment for third-party JavaScript code to run in, this is a much easier way to address the security problem than to suggest we have to wait for ES-Harmony to add extra syntax to the language to accomplish the same thing.

[[User:Getify|Getify]] 02:13, 2 November 2010 (UTC)

== Text/cache solution ==

It seems to me that having a real text/cache script type, or a similar element that fires a load/error event and provides a .text property gets you where you need to be. You could setAttribute("type", "text/JavaScript") or use the text to create a new script element. Or a new style element, or whatever. That puts you in control of when script or CSS is interpreted. With async as the default, you don't need a new ordered attribute as that's easily managed in script.

== "text/cache" response ==

On the surface, this idea sounds like it's pretty similar to <link rel=prefetch> -- in other words, we've already standardized a way to prefetch a resource into cache, and probably in a better way than the hack that I did in LABjs of just relying on it fetching unrecognizable content.

Unfortunately, it still suffers some similar problems to <link rel=prefetch>.

Firstly, if the notion is that you'd use <script type="text/cache"> to prefetch, and then you'd make a second request for the resource with a real <script type="text/javascript> node, it suffers the faulty assumption that the resource was served with proper cache headers.

If we try to avoid the need for the second request by suggesting that you can access the `text` property of the node (and then eval() or inject that code when you want to execute it), this runs afoul of the same-origin policy problem if you requested the script from a non-local domain.

The part of your suggestion that holds water would be if, given a "prefetched" script node that didn't execute yet, I could simply change that node's `type` value from "text/cache" to "text/javascript", and that would explicitly trigger the browser to immediately execute it.

This is an interesting idea. I can see though that it perhaps has some potential complications.

For instance, would the browser have to keep a "hasExecuted" internal flag, so that changing the `type` value would only at most result in one execution? Also, if the script node in question is loaded but not executed, can the page alter the script code (by setting its `text` property) before making the change to the `type` value? In that case, should the browser execute the original code or the modified code? I can see security implications and confusion abounding in that behavior.

Lastly, as mentioned above, this basically copies (in a similar but not exactly identical way) the <link rel=prefetch> behavior. It may be seen as a negative to be trying to step on the toes of <link rel=prefetch>, and also it may be more confusing to the general public as to why you'd use one technique or the other, given their differences being so nuanced.

That having been said, I can see that it's a viable alternate proposal. It's worth adding a note to that section of the main Wiki page and to getting some feedback from browser vendors on if they feel this is a more realistic/suitable solution to the use-case.
<blockquote style="background-color: #eee">
The difference between pre-fetching and this proposal seems pretty clear: Prefetching, if not performed now, will eventually be done once the user explicitly requests the page. while the "text/cache" solution indicates that the resource should load '''immediately''', not during idle time.

<br/>
[[User:Serverherder|Serverherder]] 19:10, 15 December 2010 (UTC)
</blockquote>

[[User:Getify|Getify]] 20:56, 4 November 2010 (UTC)

== RequireJS order support ==

I am the main developer for RequireJS, and just want to voice my support for a solution that works on the script element itself, either by leveraging the async attribute or allowing something like an "order" boolean attribute that would allow specifying a dynamically added script element should be executed in the order that it appears in the DOM. This capability should be something can be capability detected to avoid browser sniffing.
<blockquote style="background-color:#eee">
Why shouldn't dependency management be implemented in high-level code and the browser simply provide a means by which parallel loading can be achieved? As you know, there is a considerable amount of nuance. I'm of the opinion that implementing dependency management in the engine will eventually lead us right back to where we were 10 years ago with inline script tags which provides an easy method for dependency management at the expense of unmanaged blocking and an inability to detect or adapt to errors. <br/>
[[User:Serverherder|Serverherder]] 19:51, 15 December 2010 (UTC)
</blockquote>

There are many scripts on the web today that have implicit dependencies that should be loaded in a specific order, but the application developer will want to use dynamically created script elements for best performance. jQuery plugins that depend on the jQuery script already been executed in the page are a good example.
<blockquote style="background-color:#eee">
Agreed, but I don't believe the proposals allow for proper emulation of the dependency management provided by script tags. Prototype.js, for example, loads its core modules dynamically (using document.write so maybe not the best example...). When prototype.js is included via script tags, ensuing script blocks are free to "depend" on all of these modules; Dynamically creating a dependency on prototype.js by loading both with the `async=true` property will fail since prototype.js won't be able to "jump the queue" and add insure its core modules load before its extensions. <br/>
[[User:Serverherder|Serverherder]] 19:51, 15 December 2010 (UTC)

<blockquote style="background-color:#ccc">
I have to admit, you raise a valid point with respect to that common usage. The YUI model (where the framework is responsible for all loading) is perhaps the more appropriate model to move toward, though. Or, the framework doesn't auto-load its own dependencies at all. In either case, I think it's cleaner to have one loading mechanism in play rather than two or more competing ones, because as you point out, this is going to get messy. I still am not sure this means that the async=false proposal is lacking, because as I think about how complicated such a split loading would be with your `readyState` proposal, that seems even worse/more complicated to me. [[User:Getify|Getify]] 20:06, 15 December 2010 (UTC)
</blockquote>
<blockquote style="background-color:#eee">

I would not argue '''against''' a global queue for synchronized execution, I just think the usefulness of such a construct declines as scripts that "I don't care about" are added. It's my opinion the spec should provide the ability for high-level code to implement similar constructs, regardless of how complex it may be to do so. <br/>
<br>
That being said, I don't think it's any more complicated than existing models. Here's a demonstration of an [http://digital-fulcrum.com/executionorder/ IE-only parallel-loading, synchronously-executing script queue] implemented in 40 lines of code. It tests both cached and un-cached scripts (from the LABjs test suite) and has been tested and found to be working in IE6-8.
<br>
[[User:Serverherder|Serverherder]] 01:52, 16 December 2010 (UTC)
</blockquote>
</blockquote>

- James Burke

== Vendors Should Implement the Existing Suggestion ==

Since the spec all ready includes a suggestion to download resources when the SRC attribute is set, parallel loading is an option the '''vendor''' chooses to implement and not something a script loader should be able to require. Vendors that don't implement the suggestion will run the risk of being less performant in these situations. That, however, is '''their''' choice to make as the spec suggests. If the benefits of parallel loading dependencies are so great, users will opt for this in their choice of agent or vendors can adopt the existing mechanism.

== The Current Suggestion Should be Changed to a Mandate ==

The spec is pretty clear on why it chose to make this optional. If dependent script loading is so common that browsers that adopt the suggestion enjoy considerably better performance, the user will eventually decide to opt for those implementations. On the other hand, if it is more common that scripts are created and never inserted, leading to wasted bandwidth and clogged fetching queues, the converse will occur. Either way, by making it optional, the spec hedges its bet and is more prone to be future-proof as the habits of script developers evolve.

== Modify the specification so parallel-loading is configurable ==
The specification expresses the reasons parallel loading should not be done. To this point, allowing developers a means to '''require''' resources be downloaded in parallel is in direct opposition to the spec's all ready stated position. To this end, I see no purpose for async=true: A browser that hopes to be highly performant should implement the spec's suggestion to improve performance. Developers should not be able to circumvent the vendor's attempt to be conservative in its use of bandwidth simply to achieve ordered execution.

=== response ===
Nothing about this proposal requires any parallelism that the browser wouldn't already afford. The spirit of this proposal is not about loading behavior, but about execution order.

The spec says nothing about the parallel loading, nor do I think it should necessarily. All modern browsers HAVE in fact implemented parallel loading for all scripts, regardless of async or not. And I think this is a good thing. But it has nothing to do with `async` or my proposal to make the definition of `async` symmetric/consistent between markup script elements and dynamic script elements.

The spec already defines that `async` is specifically to create unblocking of the page's resource loading AND "as soon as possible" execution of the script. But it only defines this for parser-inserted (markup) script tags. I think this is short-sighted, because I think a script-loader should be able to opt into either ordered or unordered execution in the same way that markup script elements can. That's really all the main proposal is about.

<blockquote style="background-color:#EEE">
Script loaders can all ready choose ordered execution: chain the onload events. The issue is that vendors have chosen '''not''' to adopt the specification's suggestion. The high priority vendors place on performance suggests this was not done consciously. Instead of advocating WHATWG for additions to the spec, I think we may be better off advocating vendors implement the spec's suggestion. The existing implementation of parallelism for parser-inserted scripts suggests vendors would be willing to do so and the existing lack of support is merely an issue of communication.

At its core, the existing suggestion to retrieve upon src assignment is not altogether different than the eager-fetching performed for parser-inserted scripts. The risk still exists that the browser download a script that is never actually executed. For example, below a bunch of script tags, the HTML may contain a closing comment tag (-->) and one of the scripts doc.write("<\!--"). Another risk is that the eager-fetching clog the fetch queue, delaying the download of any scripts included via document.write(). Vendors have '''chosen''' to assume this risk though, since its probability is low and the benefit high.

Likewise, vendors can calculate the risk/reward for script-inserted scripts and will likely make the same decision -- they implement this exact behavior for images. Script loaders should respect the fact that a vendor has consciously chosen '''not''' to support parallelism for script-inserted scripts. Providing a means by which this decision can be circumvented undermines their choice. I believe it was in that spirit the specification leaves eager fetching script resources as a suggestion.

<blockquote style="background-color:#ccc">
I think you still miss the pragmatic point here. I'm not disagreeing with you in theory, but in practice, the hard-nosed approach you suggest would spell death for any script loader. That's not a chance I'm willing to take.

When a developer uses a script loader that claims it is "The Performance Script Loader" (as LABjs does), and they test in some latest-version browser (whether that be FF, Safari, Chrome, IE, or Opera) and the performance is terrible (worse than before they installed LABjs), they're not going to say, "Well, I'll just keep LABjs in there and hope those browsers fix this quickly".

This is tail-wagging-the-dog mentality, and it ignores the reality: people will almost always chose the path of least resistance. If they try a script loader, and it gives them worse performance than before, they'll simply take it out. They may complain about it once in a tweet, but they won't take a stand against the browsers to the detriment of their own site and their own users, and they won't tell all their users to switch to another browser in protest.

And worse, for LABjs, the path of least resistance may very well mean that if performance is important to them, they'll just pick some other loader, which has more hacks in it. As long as they get what they want, which is reliable and pretty good performance, they'll be happy. And it will totally have been lost on them that the battle for web standards was just dealt a blow by their actions. General web page authors do not care to fight that battle on behalf of LABjs. So, LABjs must fight that battle under the covers.

I understand your perspective, but I can say as the maintainer of a tool like LABjs that cares about keeping its relevancy for "survival", I won't take an action that I know is likely to cause a decline in the usefulness of my tool. Instead, I will take a more cautious, slow-to-change approach, while at the same time feature-testing for the new standards and using them if available. Only after a long time of the new feature-testable stuff being present will I consider removing the legacy stuff. This is a strategy I think almost every framework/lib maintainer would echo support for.

[[User:Getify|Getify]] 00:50, 24 December 2010 (UTC)

</blockquote>

[[User:Getify|Getify]] 21:39, 23 December 2010 (UTC)

<blockquote style="background-color: white">
<p> A phased approach toward adopting this is reasonable and you clearly state the risks of both positions. My comments have derailed the true purpose of this discussion: ''Does the specification require modification''? Since the spec all ready provides a mechanism by which this functionality can be achieved, I believe it is best to reword the suggestion so it more appropriately conveys the importance of it, but don't think the behavior should be imposed on vendors.
[[User:Serverherder|Serverherder]]

Talk:Dynamic Script Execution Order

2010-12-23T22:58:18Z

Serverherder: /* response */

Please discuss the proposal here. All informal feedback is welcomed, and when it's appropriate, please add content to the main page.

== What about CommonJS / RequireJS? ==

I'm not sure we need to complicate the HTML or browser engines in order to satisfy the advanced use cases. To me it seems that the JavaScript langauge itself could abstract the requirements and let the browser vendors implement whatever solution they see fit. Specifically, if JavaScript provided the define() and require() calls proposed in the CommonJS "specifications" (and implemented by [http://requirejs.org/docs/api.html RequireJS], [http://svn.dojotoolkit.org/src/dojo/trunk/_base/_loader/loader.js dojo (trunk)], and others *Yabble?), then browsers could just load and evaluate scripts as fast as possible without regard to script execution order.

This would solve all of the problems except for the current inability to use loaders like LABjs in FF4 or webkit. To solve that problem, we should consider keeping the existing functionality or triggering the deprecated functionality when needed.

--[[User:Unscriptable|Unscriptable]] 01:29, 2 November 2010 (UTC)

=== Response ===

This is a valid point except that it assumes that all code that needs to be loaded is "modular"... in fact, most code on the internet that needs to be loaded is NOT modular, and instead requires particular ordering when being loaded... for instance, "jquery" and "jquery-ui" -- jQuery must be run before jQuery-UI is loaded and run.

The spirit of this proposal is to add the facility to native browser (rendering engine, specifically) behavior, such that any and all existing content is able to be loaded (even with dependencies and order) without modification.
<blockquote style=background-color:#eee>
Are we trying to codify how one would implement this HTML dynamically so I can achieve parallel loading but retain dependency that is inferred in the order?

<blockquote style="background-color: white">
<script src="jquery.js"> </script> <br/>
<script src="jquery-ui.js"> </script>
</blockquote>

If so, we must consider the case in which the dependency itself loads additional code which the discussions around `async=false` or even text/cache do not account for.
[[User:Serverherder|Serverherder]] 19:23, 15 December 2010 (UTC)
</blockquote>

=== Dependent code should be modular ===

I completely agree, 99% of JavaScript in use today is NOT modular, but that's arguably because there was no built-in support to make it modular (IMHO, YMMV, RTFM, BBQ, ROFL). But that doesn't mean there aren't dependencies that span script files / script nodes. I don't know how many sites would be broken (or if there is any way to determine how many sites would be broken) if/when the latest browsers started loading and evaluating script-injected scripts out of order. It's not just LABjs-based sites. I'll bet many dojo and YUI sites will break, too (although I don't know this for a fact because I don't know exactly how their dynamic script loaders work).

'''''In any case, breaking existing sites is a BAD IDEA. :) There should be some way to allow LABjs and other dynamic script loaders to continue to work.'''''

The part I don't agree with in the proposals is that it should be the job of HTML and/or the browser engine to manage dependencies. Specifically, I am talking about the scriptGroup element and the "waitFor" attribute. The "async" attribute may be the right level: it appropriates only general heuristics to the browser: ''load these scripts whenever you like, but load these other scripts in this order''.

Detailed dependency management belongs in the modules, though. This is how it's done in most environments / languages: import statements, include statements, etc. It's no different in JavaScript, if a developer wants to take advantage of some code in another module, she/he should import it into their current module. This should be the model moving forward. It's not hard, it's not un-web-like, and it's already being done.

Existing code can be made to work modularly, too:

1. Identify modules and wrap them with a define() method.
2. Identify dependencies using either the [http://wiki.commonjs.org/wiki/Modules/AsynchronousDefinition Asynchronous Module Definition] format or the CommonJS synchronous format

async format:
<pre lang="javascript">
define(['dependency1', 'dependency2'], function (dependency1, dependency2) {
/* this is the factory function, return the module inside here */
return { /* some object, but could also be a constructor or a function */ };
});
</pre>
sync format:
<pre lang="javascript">
define(function (require, exports, module) {
/* this is the factory function, require dependencies and return the module inside here */
var dependency1 = require('dependency1');
var dependency2 = require('dependency2');
return { /* some object, but could also be a constructor or a function */ };
});
</pre>
In the async case, the browser may employ whatever method it sees fit (e.g. parallel) to download the dependencies since the code inside the factory function won't execute until all of the dependencies are loaded and evaluated. In the sync case, the browser has no choice but to download and evaluate the dependency before continuing code execution. It's conceivable that the browser could find and asynchronously pre-fetch the inline require()'ed dependencies in the sync case. (RequireJS doesn't quite do this. Instead I believe it finds the inline require() calls and converts the module to an async module.)

'''''So, in short: don't break LABjs (or any other script loaders), but don't extend the spec to manage dependency management from HTML.'''''

--[[User:Unscriptable|Unscriptable]] 01:29, 2 November 2010 (UTC)

== Response #2 ==

The cat's already out of the bag... we've got a dozen+ years worth, hundreds of millions of javascript files out there, which are NOT modular, and will not be modified to be modular.

If we're talking about either trying to change all the JS on the web to be modular, or trying to extend the HTML markup spec to include a better facility for accomodating the existing script content, I think the former is idealistic and "correct" but the latter is realistic and "right".

A modular loading system will only work for modular code, but a general loading mechanism in HTML (like the <script> tag) can load both modular and non-modular code, which is why that more general mechanism is what's in HTML right now and not some more specialized loading API that only loads a small percentage of JavaScript code out there.

The <script> tag has worked fine forever, and there's been no real big push to do away with it in favor of having all loading handled by JavaScript -- in fact, that would be impossible because if you had no way to load JS onto the page with a <script> tag, then no JavaScript could run on a page to load more code. So I don't agree that we should stop adding functionality to the HTML loading mechanism and only focus on JavaScript.

If we agree that the <script> tag itself is not only required but normative, then I'm not sure why decorating the <script> tag with additional behavior to help it be more powerful is a bad pattern. We've addded "defer" and "async" already. I'm not sure I understand why adding a wrapper tag called "scriptGroup" would be that much different than attributes on the <script> tag?

I also don't think that "scriptGroup" constitutes "dependency management". "scriptGroup" is a semantic way for a web author to express that they want to group a set of scripts together ONLY so far as execution order behavior is concerned. It implies nothing more to it (that "dependency management" would imply) than that.

For instance, consider this: if JavaScript had been built with non-global context and statement level context and sandboxing and such things, we'd have a much more secure JavaScript right now. But just because JavaScript may someday be taught some new tricks in terms of security, that doesn't mean that "now" HTML shouldn't try to help solve the problem. If for instance the <frag> tag can be used to create a sandboxed environment for third-party JavaScript code to run in, this is a much easier way to address the security problem than to suggest we have to wait for ES-Harmony to add extra syntax to the language to accomplish the same thing.

[[User:Getify|Getify]] 02:13, 2 November 2010 (UTC)

== Text/cache solution ==

It seems to me that having a real text/cache script type, or a similar element that fires a load/error event and provides a .text property gets you where you need to be. You could setAttribute("type", "text/JavaScript") or use the text to create a new script element. Or a new style element, or whatever. That puts you in control of when script or CSS is interpreted. With async as the default, you don't need a new ordered attribute as that's easily managed in script.

== "text/cache" response ==

On the surface, this idea sounds like it's pretty similar to <link rel=prefetch> -- in other words, we've already standardized a way to prefetch a resource into cache, and probably in a better way than the hack that I did in LABjs of just relying on it fetching unrecognizable content.

Unfortunately, it still suffers some similar problems to <link rel=prefetch>.

Firstly, if the notion is that you'd use <script type="text/cache"> to prefetch, and then you'd make a second request for the resource with a real <script type="text/javascript> node, it suffers the faulty assumption that the resource was served with proper cache headers.

If we try to avoid the need for the second request by suggesting that you can access the `text` property of the node (and then eval() or inject that code when you want to execute it), this runs afoul of the same-origin policy problem if you requested the script from a non-local domain.

The part of your suggestion that holds water would be if, given a "prefetched" script node that didn't execute yet, I could simply change that node's `type` value from "text/cache" to "text/javascript", and that would explicitly trigger the browser to immediately execute it.

This is an interesting idea. I can see though that it perhaps has some potential complications.

For instance, would the browser have to keep a "hasExecuted" internal flag, so that changing the `type` value would only at most result in one execution? Also, if the script node in question is loaded but not executed, can the page alter the script code (by setting its `text` property) before making the change to the `type` value? In that case, should the browser execute the original code or the modified code? I can see security implications and confusion abounding in that behavior.

Lastly, as mentioned above, this basically copies (in a similar but not exactly identical way) the <link rel=prefetch> behavior. It may be seen as a negative to be trying to step on the toes of <link rel=prefetch>, and also it may be more confusing to the general public as to why you'd use one technique or the other, given their differences being so nuanced.

That having been said, I can see that it's a viable alternate proposal. It's worth adding a note to that section of the main Wiki page and to getting some feedback from browser vendors on if they feel this is a more realistic/suitable solution to the use-case.
<blockquote style="background-color: #eee">
The difference between pre-fetching and this proposal seems pretty clear: Prefetching, if not performed now, will eventually be done once the user explicitly requests the page. while the "text/cache" solution indicates that the resource should load '''immediately''', not during idle time.

<br/>
[[User:Serverherder|Serverherder]] 19:10, 15 December 2010 (UTC)
</blockquote>

[[User:Getify|Getify]] 20:56, 4 November 2010 (UTC)

== RequireJS order support ==

I am the main developer for RequireJS, and just want to voice my support for a solution that works on the script element itself, either by leveraging the async attribute or allowing something like an "order" boolean attribute that would allow specifying a dynamically added script element should be executed in the order that it appears in the DOM. This capability should be something can be capability detected to avoid browser sniffing.
<blockquote style="background-color:#eee">
Why shouldn't dependency management be implemented in high-level code and the browser simply provide a means by which parallel loading can be achieved? As you know, there is a considerable amount of nuance. I'm of the opinion that implementing dependency management in the engine will eventually lead us right back to where we were 10 years ago with inline script tags which provides an easy method for dependency management at the expense of unmanaged blocking and an inability to detect or adapt to errors. <br/>
[[User:Serverherder|Serverherder]] 19:51, 15 December 2010 (UTC)
</blockquote>

There are many scripts on the web today that have implicit dependencies that should be loaded in a specific order, but the application developer will want to use dynamically created script elements for best performance. jQuery plugins that depend on the jQuery script already been executed in the page are a good example.
<blockquote style="background-color:#eee">
Agreed, but I don't believe the proposals allow for proper emulation of the dependency management provided by script tags. Prototype.js, for example, loads its core modules dynamically (using document.write so maybe not the best example...). When prototype.js is included via script tags, ensuing script blocks are free to "depend" on all of these modules; Dynamically creating a dependency on prototype.js by loading both with the `async=true` property will fail since prototype.js won't be able to "jump the queue" and add insure its core modules load before its extensions. <br/>
[[User:Serverherder|Serverherder]] 19:51, 15 December 2010 (UTC)

<blockquote style="background-color:#ccc">
I have to admit, you raise a valid point with respect to that common usage. The YUI model (where the framework is responsible for all loading) is perhaps the more appropriate model to move toward, though. Or, the framework doesn't auto-load its own dependencies at all. In either case, I think it's cleaner to have one loading mechanism in play rather than two or more competing ones, because as you point out, this is going to get messy. I still am not sure this means that the async=false proposal is lacking, because as I think about how complicated such a split loading would be with your `readyState` proposal, that seems even worse/more complicated to me. [[User:Getify|Getify]] 20:06, 15 December 2010 (UTC)
</blockquote>
<blockquote style="background-color:#eee">

I would not argue '''against''' a global queue for synchronized execution, I just think the usefulness of such a construct declines as scripts that "I don't care about" are added. It's my opinion the spec should provide the ability for high-level code to implement similar constructs, regardless of how complex it may be to do so. <br/>
<br>
That being said, I don't think it's any more complicated than existing models. Here's a demonstration of an [http://digital-fulcrum.com/executionorder/ IE-only parallel-loading, synchronously-executing script queue] implemented in 40 lines of code. It tests both cached and un-cached scripts (from the LABjs test suite) and has been tested and found to be working in IE6-8.
<br>
[[User:Serverherder|Serverherder]] 01:52, 16 December 2010 (UTC)
</blockquote>
</blockquote>

- James Burke

== Vendors Should Implement the Existing Suggestion ==

Since the spec all ready includes a suggestion to download resources when the SRC attribute is set, parallel loading is an option the '''vendor''' chooses to implement and not something a script loader should be able to require. Vendors that don't implement the suggestion will run the risk of being less performant in these situations. That, however, is '''their''' choice to make as the spec suggests. If the benefits of parallel loading dependencies are so great, users will opt for this in their choice of agent or vendors can adopt the existing mechanism.

== The Current Suggestion Should be Changed to a Mandate ==

The spec is pretty clear on why it chose to make this optional. If dependent script loading is so common that browsers that adopt the suggestion enjoy considerably better performance, the user will eventually decide to opt for those implementations. On the other hand, if it is more common that scripts are created and never inserted, leading to wasted bandwidth and clogged fetching queues, the converse will occur. Either way, by making it optional, the spec hedges its bet and is more prone to be future-proof as the habits of script developers evolve.

== Modify the specification so parallel-loading is configurable ==
The specification expresses the reasons parallel loading should not be done. To this point, allowing developers a means to '''require''' resources be downloaded in parallel is in direct opposition to the spec's all ready stated position. To this end, I see no purpose for async=true: A browser that hopes to be highly performant should implement the spec's suggestion to improve performance. Developers should not be able to circumvent the vendor's attempt to be conservative in its use of bandwidth simply to achieve ordered execution.

=== response ===
Nothing about this proposal requires any parallelism that the browser wouldn't already afford. The spirit of this proposal is not about loading behavior, but about execution order.

The spec says nothing about the parallel loading, nor do I think it should necessarily. All modern browsers HAVE in fact implemented parallel loading for all scripts, regardless of async or not. And I think this is a good thing. But it has nothing to do with `async` or my proposal to make the definition of `async` symmetric/consistent between markup script elements and dynamic script elements.

The spec already defines that `async` is specifically to create unblocking of the page's resource loading AND "as soon as possible" execution of the script. But it only defines this for parser-inserted (markup) script tags. I think this is short-sighted, because I think a script-loader should be able to opt into either ordered or unordered execution in the same way that markup script elements can. That's really all the main proposal is about.

<blockquote style="background-color:#EEE">
Script loaders can all ready choose ordered execution: chain the onload events. The issue is that vendors have chosen '''not''' to adopt the specification's suggestion. The high priority vendors place on performance suggests this was not done consciously. Instead of advocating WHATWG for additions to the spec, I think we may be better off advocating vendors implement the spec's suggestion. The existing implementation of parallelism for parser-inserted scripts suggests vendors would be willing to do so and the existing lack of support is merely an issue of communication.

At its core, the existing suggestion to retrieve upon src assignment is not altogether different than the eager-fetching performed for parser-inserted scripts. The risk still exists that the browser download a script that is never actually executed. For example, below a bunch of script tags, the HTML may contain a closing comment tag (-->) and one of the scripts doc.write("<!--"). Another risk is that the eager-fetching clog the fetch queue, delaying the download of any scripts included via document.write(). Vendors have '''chosen''' to assume this risk though, since its probability is low and the benefit high.

Likewise, vendors can calculate the risk/reward for script-inserted scripts and will likely make the same decision -- they implement this exact behavior for images. Script loaders should respect the fact that a vendor has consciously chosen '''not''' to support parallelism for script-inserted scripts. Providing a means by which this decision can be circumvented undermines their choice. I believe it was in that spirit the specification leaves eager fetching script resources as a suggestion.

</blockquote>

[[User:Getify|Getify]] 21:39, 23 December 2010 (UTC)

Talk:Dynamic Script Execution Order

2010-12-23T21:14:14Z

Serverherder: /* Encourage Vendors to Adopt the Current Performance Suggestion */

Talk:Dynamic Script Execution Order

2010-12-23T21:09:44Z

Serverherder: /* Encourage Vendors to Adopt the Current Performance Suggestion */ new section

Please discuss the proposal here. All informal feedback is welcomed, and when it's appropriate, please add content to the main page.

== What about CommonJS / RequireJS? ==

I'm not sure we need to complicate the HTML or browser engines in order to satisfy the advanced use cases. To me it seems that the JavaScript langauge itself could abstract the requirements and let the browser vendors implement whatever solution they see fit. Specifically, if JavaScript provided the define() and require() calls proposed in the CommonJS "specifications" (and implemented by [http://requirejs.org/docs/api.html RequireJS], [http://svn.dojotoolkit.org/src/dojo/trunk/_base/_loader/loader.js dojo (trunk)], and others *Yabble?), then browsers could just load and evaluate scripts as fast as possible without regard to script execution order.

This would solve all of the problems except for the current inability to use loaders like LABjs in FF4 or webkit. To solve that problem, we should consider keeping the existing functionality or triggering the deprecated functionality when needed.

--[[User:Unscriptable|Unscriptable]] 01:29, 2 November 2010 (UTC)

=== Response ===

This is a valid point except that it assumes that all code that needs to be loaded is "modular"... in fact, most code on the internet that needs to be loaded is NOT modular, and instead requires particular ordering when being loaded... for instance, "jquery" and "jquery-ui" -- jQuery must be run before jQuery-UI is loaded and run.

The spirit of this proposal is to add the facility to native browser (rendering engine, specifically) behavior, such that any and all existing content is able to be loaded (even with dependencies and order) without modification.
<blockquote style=background-color:#eee>
Are we trying to codify how one would implement this HTML dynamically so I can achieve parallel loading but retain dependency that is inferred in the order?

<blockquote style="background-color: white">
<script src="jquery.js"> </script> <br/>
<script src="jquery-ui.js"> </script>
</blockquote>

If so, we must consider the case in which the dependency itself loads additional code which the discussions around `async=false` or even text/cache do not account for.
[[User:Serverherder|Serverherder]] 19:23, 15 December 2010 (UTC)
</blockquote>

=== Dependent code should be modular ===

I completely agree, 99% of JavaScript in use today is NOT modular, but that's arguably because there was no built-in support to make it modular (IMHO, YMMV, RTFM, BBQ, ROFL). But that doesn't mean there aren't dependencies that span script files / script nodes. I don't know how many sites would be broken (or if there is any way to determine how many sites would be broken) if/when the latest browsers started loading and evaluating script-injected scripts out of order. It's not just LABjs-based sites. I'll bet many dojo and YUI sites will break, too (although I don't know this for a fact because I don't know exactly how their dynamic script loaders work).

'''''In any case, breaking existing sites is a BAD IDEA. :) There should be some way to allow LABjs and other dynamic script loaders to continue to work.'''''

The part I don't agree with in the proposals is that it should be the job of HTML and/or the browser engine to manage dependencies. Specifically, I am talking about the scriptGroup element and the "waitFor" attribute. The "async" attribute may be the right level: it appropriates only general heuristics to the browser: ''load these scripts whenever you like, but load these other scripts in this order''.

Detailed dependency management belongs in the modules, though. This is how it's done in most environments / languages: import statements, include statements, etc. It's no different in JavaScript, if a developer wants to take advantage of some code in another module, she/he should import it into their current module. This should be the model moving forward. It's not hard, it's not un-web-like, and it's already being done.

Existing code can be made to work modularly, too:

1. Identify modules and wrap them with a define() method.
2. Identify dependencies using either the [http://wiki.commonjs.org/wiki/Modules/AsynchronousDefinition Asynchronous Module Definition] format or the CommonJS synchronous format

async format:
<pre lang="javascript">
define(['dependency1', 'dependency2'], function (dependency1, dependency2) {
/* this is the factory function, return the module inside here */
return { /* some object, but could also be a constructor or a function */ };
});
</pre>
sync format:
<pre lang="javascript">
define(function (require, exports, module) {
/* this is the factory function, require dependencies and return the module inside here */
var dependency1 = require('dependency1');
var dependency2 = require('dependency2');
return { /* some object, but could also be a constructor or a function */ };
});
</pre>
In the async case, the browser may employ whatever method it sees fit (e.g. parallel) to download the dependencies since the code inside the factory function won't execute until all of the dependencies are loaded and evaluated. In the sync case, the browser has no choice but to download and evaluate the dependency before continuing code execution. It's conceivable that the browser could find and asynchronously pre-fetch the inline require()'ed dependencies in the sync case. (RequireJS doesn't quite do this. Instead I believe it finds the inline require() calls and converts the module to an async module.)

'''''So, in short: don't break LABjs (or any other script loaders), but don't extend the spec to manage dependency management from HTML.'''''

--[[User:Unscriptable|Unscriptable]] 01:29, 2 November 2010 (UTC)

== Response #2 ==

The cat's already out of the bag... we've got a dozen+ years worth, hundreds of millions of javascript files out there, which are NOT modular, and will not be modified to be modular.

If we're talking about either trying to change all the JS on the web to be modular, or trying to extend the HTML markup spec to include a better facility for accomodating the existing script content, I think the former is idealistic and "correct" but the latter is realistic and "right".

A modular loading system will only work for modular code, but a general loading mechanism in HTML (like the <script> tag) can load both modular and non-modular code, which is why that more general mechanism is what's in HTML right now and not some more specialized loading API that only loads a small percentage of JavaScript code out there.

The <script> tag has worked fine forever, and there's been no real big push to do away with it in favor of having all loading handled by JavaScript -- in fact, that would be impossible because if you had no way to load JS onto the page with a <script> tag, then no JavaScript could run on a page to load more code. So I don't agree that we should stop adding functionality to the HTML loading mechanism and only focus on JavaScript.

If we agree that the <script> tag itself is not only required but normative, then I'm not sure why decorating the <script> tag with additional behavior to help it be more powerful is a bad pattern. We've addded "defer" and "async" already. I'm not sure I understand why adding a wrapper tag called "scriptGroup" would be that much different than attributes on the <script> tag?

I also don't think that "scriptGroup" constitutes "dependency management". "scriptGroup" is a semantic way for a web author to express that they want to group a set of scripts together ONLY so far as execution order behavior is concerned. It implies nothing more to it (that "dependency management" would imply) than that.

For instance, consider this: if JavaScript had been built with non-global context and statement level context and sandboxing and such things, we'd have a much more secure JavaScript right now. But just because JavaScript may someday be taught some new tricks in terms of security, that doesn't mean that "now" HTML shouldn't try to help solve the problem. If for instance the <frag> tag can be used to create a sandboxed environment for third-party JavaScript code to run in, this is a much easier way to address the security problem than to suggest we have to wait for ES-Harmony to add extra syntax to the language to accomplish the same thing.

[[User:Getify|Getify]] 02:13, 2 November 2010 (UTC)

== Text/cache solution ==

It seems to me that having a real text/cache script type, or a similar element that fires a load/error event and provides a .text property gets you where you need to be. You could setAttribute("type", "text/JavaScript") or use the text to create a new script element. Or a new style element, or whatever. That puts you in control of when script or CSS is interpreted. With async as the default, you don't need a new ordered attribute as that's easily managed in script.

== "text/cache" response ==

On the surface, this idea sounds like it's pretty similar to <link rel=prefetch> -- in other words, we've already standardized a way to prefetch a resource into cache, and probably in a better way than the hack that I did in LABjs of just relying on it fetching unrecognizable content.

Unfortunately, it still suffers some similar problems to <link rel=prefetch>.

Firstly, if the notion is that you'd use <script type="text/cache"> to prefetch, and then you'd make a second request for the resource with a real <script type="text/javascript> node, it suffers the faulty assumption that the resource was served with proper cache headers.

If we try to avoid the need for the second request by suggesting that you can access the `text` property of the node (and then eval() or inject that code when you want to execute it), this runs afoul of the same-origin policy problem if you requested the script from a non-local domain.

The part of your suggestion that holds water would be if, given a "prefetched" script node that didn't execute yet, I could simply change that node's `type` value from "text/cache" to "text/javascript", and that would explicitly trigger the browser to immediately execute it.

This is an interesting idea. I can see though that it perhaps has some potential complications.

For instance, would the browser have to keep a "hasExecuted" internal flag, so that changing the `type` value would only at most result in one execution? Also, if the script node in question is loaded but not executed, can the page alter the script code (by setting its `text` property) before making the change to the `type` value? In that case, should the browser execute the original code or the modified code? I can see security implications and confusion abounding in that behavior.

Lastly, as mentioned above, this basically copies (in a similar but not exactly identical way) the <link rel=prefetch> behavior. It may be seen as a negative to be trying to step on the toes of <link rel=prefetch>, and also it may be more confusing to the general public as to why you'd use one technique or the other, given their differences being so nuanced.

That having been said, I can see that it's a viable alternate proposal. It's worth adding a note to that section of the main Wiki page and to getting some feedback from browser vendors on if they feel this is a more realistic/suitable solution to the use-case.
<blockquote style="background-color: #eee">
The difference between pre-fetching and this proposal seems pretty clear: Prefetching, if not performed now, will eventually be done once the user explicitly requests the page. while the "text/cache" solution indicates that the resource should load '''immediately''', not during idle time.

<br/>
[[User:Serverherder|Serverherder]] 19:10, 15 December 2010 (UTC)
</blockquote>

[[User:Getify|Getify]] 20:56, 4 November 2010 (UTC)

== RequireJS order support ==

I am the main developer for RequireJS, and just want to voice my support for a solution that works on the script element itself, either by leveraging the async attribute or allowing something like an "order" boolean attribute that would allow specifying a dynamically added script element should be executed in the order that it appears in the DOM. This capability should be something can be capability detected to avoid browser sniffing.
<blockquote style="background-color:#eee">
Why shouldn't dependency management be implemented in high-level code and the browser simply provide a means by which parallel loading can be achieved? As you know, there is a considerable amount of nuance. I'm of the opinion that implementing dependency management in the engine will eventually lead us right back to where we were 10 years ago with inline script tags which provides an easy method for dependency management at the expense of unmanaged blocking and an inability to detect or adapt to errors. <br/>
[[User:Serverherder|Serverherder]] 19:51, 15 December 2010 (UTC)
</blockquote>

There are many scripts on the web today that have implicit dependencies that should be loaded in a specific order, but the application developer will want to use dynamically created script elements for best performance. jQuery plugins that depend on the jQuery script already been executed in the page are a good example.
<blockquote style="background-color:#eee">
Agreed, but I don't believe the proposals allow for proper emulation of the dependency management provided by script tags. Prototype.js, for example, loads its core modules dynamically (using document.write so maybe not the best example...). When prototype.js is included via script tags, ensuing script blocks are free to "depend" on all of these modules; Dynamically creating a dependency on prototype.js by loading both with the `async=true` property will fail since prototype.js won't be able to "jump the queue" and add insure its core modules load before its extensions. <br/>
[[User:Serverherder|Serverherder]] 19:51, 15 December 2010 (UTC)

<blockquote style="background-color:#ccc">
I have to admit, you raise a valid point with respect to that common usage. The YUI model (where the framework is responsible for all loading) is perhaps the more appropriate model to move toward, though. Or, the framework doesn't auto-load its own dependencies at all. In either case, I think it's cleaner to have one loading mechanism in play rather than two or more competing ones, because as you point out, this is going to get messy. I still am not sure this means that the async=false proposal is lacking, because as I think about how complicated such a split loading would be with your `readyState` proposal, that seems even worse/more complicated to me. [[User:Getify|Getify]] 20:06, 15 December 2010 (UTC)
</blockquote>
<blockquote style="background-color:#eee">

I would not argue '''against''' a global queue for synchronized execution, I just think the usefulness of such a construct declines as scripts that "I don't care about" are added. It's my opinion the spec should provide the ability for high-level code to implement similar constructs, regardless of how complex it may be to do so. <br/>
<br>
That being said, I don't think it's any more complicated than existing models. Here's a demonstration of an [http://digital-fulcrum.com/executionorder/ IE-only parallel-loading, synchronously-executing script queue] implemented in 40 lines of code. It tests both cached and un-cached scripts (from the LABjs test suite) and has been tested and found to be working in IE6-8.
<br>
[[User:Serverherder|Serverherder]] 01:52, 16 December 2010 (UTC)
</blockquote>
</blockquote>

- James Burke

== Vendors Should Implement the Existing Suggestion ==

Since the spec all ready includes a suggestion to download resources when the SRC attribute is set, parallel loading is an option the '''vendor''' chooses to implement and not something a script loader should be able to require. Vendors that don't implement the suggestion will run the risk of being less performant in these situations. That, however, is '''their''' choice to make as the spec suggests. If the benefits of parallel loading dependencies are so great, users will opt for this in their choice of agent or vendors can adopt the existing mechanism.

== The Current Suggestion Should be Changed to a Mandate ==

The spec is pretty clear on why it chose to make this optional. If dependent script loading is so common that browsers that adopt the suggestion enjoy considerably better performance, the user will eventually decide to opt for those implementations. On the other hand, if it is more common that scripts are created and never inserted, leading to wasted bandwidth and clogged fetching queues, the converse will occur. Either way, by making it optional, the spec hedges its bet and is more prone to be future-proof as the habits of script developers evolve.

== Encourage Vendors to Adopt the Current Performance Suggestion ==

Yes!

Talk:Dynamic Script Execution Order

2010-12-23T21:09:08Z

Serverherder: /* The Current Suggestion Should be Changed to a Mandate */ new section

Talk:Dynamic Script Execution Order

2010-12-23T21:03:17Z

Serverherder: /* Vendors Should Implement the Existing Suggestion */ new section

Dynamic Script Execution Order

2010-12-23T20:58:48Z

Serverherder: /* Alternate Proposals */

This page is intended to formalize the discussion around an important but currently underserved use-case (in both spec and various browser implementations): the need for a dynamic script loading facility that can download resources in parallel but ensure that they execute serially in insertion order, for dependency reasons.

A long email thread on the W3C public-html list, which began [http://lists.w3.org/Archives/Public/public-html/2010Oct/0088.html here] and for which a recent message is [http://lists.w3.org/Archives/Public/public-html/2010Oct/0415.html here], has been discussing this problem, but the email thread is becoming unruly and hard to track, so this wiki page will now be the official location to discuss the topic.

Briefly, this issue has arisen because recent "nightlies" changes in both Mozilla Gecko and Webkit have broken the ability for script-loaders like [http://labjs.com LABjs] to be able to download scripts in parallel but ensure their execution order. As a result of the discussion, it's become apparent that both the spec for, and various current browser implementations around, dynamic script loading is incomplete in addressing this use case, and that some change needs to occur.

There is one main proposal that has surfaced from the discussions, with several other alternatives having been discussed. This page will try to distill the long email thread down and clearly present the main proposal, objections, and alternative suggestions.

Please feel free to join the discussion of this topic in the [[Talk:Dynamic_Script_Execution_Order]] area.

== Use Case Description ==
Script tags/elements can either:

a) appear in the HTML markup ("parser-inserted"), OR

b) be dynamically appended to the DOM using document.createElement() ("script-inserted")

Parser-inserted script tags, up until recent browser versions, had the undesirable performance behavior of loading and executing serially, blocking everything else while doing so. Recently, many browsers have improved the situation by loading the scripts in parallel, but still executing them in order.

On-demand (or dynamic) script loading has emerged in recent years for a variety of different reasons, most notably the performance improvements to address such concerns. It is desired by many different scenarios to be able to download scripts to a page completely independently of the loading of the rest of a page's resources, or even well after a page has finished loading ("on-demand").

Recent additions to HTML spec such as "defer" and "async" were intended to address the use-case for parser-inserted script elements, but their behaviors have been unhelpful for the on-demand loading use-case (script-inserted script elements).

Thus, script loaders (like [http://labjs.com LABjs]) were developed to give page authors an easy way to specify one or more scripts to load (regardless of when in the life-time of the page that loading is requested), and for as many of them as possible to load in parallel, and for those scripts to be loadable from any local or remote domain location, and for the script loader to be able to control the execution order (if the usage of the script loader's API expresses the need to) to preserve dependencies between the scripts.

Sometimes, dynamic script loading is used to load totally independent scripts, and thus "as fast as possible" execution is desired. Other times (and possibly more frequently), multiple scripts are loaded with some dependencies among them, requiring them to execute in a certain order.

What is needed is some facility by which a script loader can express that dynamic script loading either does or does not need execution order preserved among the queue of requested script loadings.

=== Current Limitations ===
Unfortunately, browser behavior around script-inserted script elements and their loading and execution behavior is splintered. There are, at present, two main camps of behavior:

a) in IE and Webkit (including Chrome), the default behavior for script-inserted script elements is for them all to execute in "as fast as possible" mode, meaning there's no guarantee about ordering. This effectively makes on-demand (dynamic) script loading impossible to work in parallel-mode if the resources in question have dependencies -- the only straight-forward way to handle things is to load each file and execute, serially, losing the parallel loading performance benefits.
<blockquote style="background-color: #EEEEEE">
I'm not sure if this is the case.

IE will start fetching resources without execution simply by setting the src attribute. Scripts will not execute, however, until they are added to the document. Since IE supports the readyState attribute and readystatechange event, it's possible to load scripts in parallel and execute them in order without resorting to invalid type attribute hack-ery.

<pre style="background-color:white" lang="javascript">
script= document.createElement("SCRIPT");
script.onreadystatechange= function(){
if(this.readyState == 'loaded')
/*
Network fetch is now complete, following
triggers synchronous execution.
*/
document.body.appendChild(this);
else if(this.readyState == "complete")
this.onreadystatechange= null;
}
script.src= "foo.js";
/* Network fetching begins now */
</pre>
</blockquote>

<blockquote style="background-color: #ccc">
I've experimented with such things heavily in the past, and I'm fairly suspicious that this is not reliable across various versions of IE (6-9), nor does it work reliably the same depending on if an element is already in the browser cache or not. I'm not 100% certain that what you suggest is flawed, but I have a strong hunch that it can be shown to have some holes in it for IE loading. I will try to create some test cases to prove or disprove.
<blockquote style="background-color: #EEEEEE">
When loading a script that is in the cache, IE requires the event handler be installed prior to setting the `src` attribute. Otherwise the element's transition to the "loaded" state will be missed. IE routinely "skips" ready state transitions when cached scripts are immediately inserted into the DOM so suspicion is understandable; however, delayed insertion works around this "problem". The script above has been tested in IE6-8 with scripts in a variety of caching states and found to work correctly.
</blockquote>

Moreover, you're suggesting something that is AFAIK only IE right now, <del>and definitely appears to not be standardized. In the same way that I'm hesitant to continue pinning loading behavior on hacks like the invalid type attribute value, I wouldn't want to approach loading with this technique (even if it were proven reliable on all IE's under all caching circumstances) unless it was a serious proposal to the W3C to have this technique be the new standard (as opposed to the current proposal, as implemented by Mozilla and Webkit now).</del>

Update: the behavior *is* in fact in the spec as a suggestion (aka, with "may" instead of "should"). The wording in question is located in [http://www.w3.org/TR/html5/scripting-1.html#running-a-script HTML5 4.3.1, "Running A Script" algorithm] step, 12, which states:

<blockquote style="background-color:#f1dac9">
For performance reasons, user agents may start fetching the script as soon as the attribute is set, instead, in the hope that the element will be inserted into the document. Either way, once the element is inserted into the document, the load must have started. If the UA performs such prefetching, but the element is never inserted in the document, or the src attribute is dynamically changed, then the user agent will not execute the script, and the fetching process will have been effectively wasted.
</blockquote>

[[User:Getify|Getify]] 19:32, 23 December 2010 (UTC)

<blockquote style="background-color: #EEEEEE">
I think you're right: Only IE impelements this event and property on script elements. The readystatechange event, however, is widely understood due to the XmlHttpRequest implementation and `readyState` property has been added to the `document` in WebKit, Mozilla and IE.
</blockquote>

That having been said, I think this is at least a viable candidate for "Alternate Proposals" and deserves to be [[Dynamic_Script_Execution_Order#readyState_.22preloading.22|listed as such]]. As always, I welcome input from the community on all the ideas presented here, including this one. But, since the main proposal (async=false) is already being implemented by at least two major browsers, I'm not sure if the tide will be changed or not.

</blockquote>

<blockquote style="background-color:#ddd;">
Also, the suggestion of handling the "preload" and deferred execution via the script tag's `readyState` property is very similar in spirit to the suggestion that was made to explicitly support [[Dynamic_Script_Execution_Order#Explicit_support_for_.22text.2Fcache.22_MIME_type_behavior|preloading into cache without execution]]. As I said, either of those two approaches might work, but they both put more of the onus of complexity in managing multiple dependencies on the high-level code (author, script loader, etc). I'm more in favor of this functionality being explicitly built-in natively into the queues. As always, I welcome comments to any side of this discussion.

[[User:Getify|Getify]] 18:35, 15 December 2010 (UTC)
</blockquote>

b) in Gecko and Opera, the default behavior for script-inserted script elements is for them all to load in parallel, but execute serially in insertion order. Technically, this makes it impossible to dynamically load independent script elements and have them execute in "as fast as possible" mode.

As described above, both behaviors are desirable under different circumstances, but each of the two camps provides only one behavior, and no way to straightforwardly achieve the other. This obviously creates a big nightmare interoperability-wise when trying to provide a general script loader cross-browser.

Since it is observed that the behavior in (a) is more detrimental (race-condition wise) for the case where dependencies exist, script loaders like LABjs had to find some way around this problem while still attempting the best possible parallel loading performance. However, the trick used is hacky and not completely reliable -- yet it is the best way to solve the use-case in <s>IE and </s>Webkit.

For Gecko/Opera, the concession was just (silently) made that the lesser-common use case of "as fast as possible" wasn't possible, but degraded fine to "insertion order execution", while keeping the parallel loading benefits.

<blockquote style="background-color: #EEEEEE">
Gecko's strict execution order creates dependencies between scripts which are unrelated and prevents the ability mitigate the impact of server outages / network latency. This is exacerbated by the fact that Gecko, unlike IE and WebKit, provides no mechanism to <b>remove</b> scripts from the execution queue.

Consider the case where JSONP is used to provide auto-completion. The user types "hello" and the JSONP request is made; however, the "currently" loading script is out-of-date as soon as the user modifies his search to "hello world". Gecko's algorithm requires the out-of-date request load and execute before the second request.
</blockquote>

Recently, Gecko landed a [http://hg.mozilla.org/mozilla-central/rev/a60414d076b5 patch] to the trunk that stopped Gecko's existing behavior of preserving execution order, making script-inserted script elements now execute in "as fast as possible" mode similiar to IE/Webkit. Unfortunately, the "workaround" used in IE/Webkit (described in the next section) for dealing with parallel loading and execution-order dependencies does not work in Gecko, which means presently the use-case in question is now broken in Gecko trunk/FF4 nightlies.

Moreover, Webkit recently landed a [http://trac.webkit.org/changeset/67245 patch] to the trunk that stopped Webkit's non-standard but long-held behavior (also used in the "workaround" described in the next section) of loading into cache script resources with an unrecognized "type" value, but silently not executing them. This behvaior (while hacky) is central to being able to address the use-case in question in Webkit, so at present, Webkit nightlies are now also entirely broken on the use-case (though in a different way than Gecko).

Both the Gecko change and the Webkit change are well-intentioned, as they are bringing the respective browser more in line with the HTML spec. However, what's really been demonstrated is that the HTML spec is not properly handling this use-case, and so the goal is not to address the browser issues raised with more awkward hacks, but to address the shortcomings of the spec first, and then encourage all browsers to adhere to such.

<blockquote style="background-color: #EEEEEE">
Considering Internet Explorer's readyState implementation provides a means of both parallel loading and preserving execution order can be achieved, perhaps its "readyState" property and onreadystatechange event should be included.
</blockquote>

=== Current Usage and Workarounds ===
To work around the limitation in IE/Webkit(prior to the above noted patch) of not being able to rely on script order execution for parallel loaded scripts, a "preloading" trick was developed. This trick relied on non-standard (but long-held) behavior in these browsers that a script-inserted script element with an unrecognized "type" value (such as "script/cache") would be fetched/loaded, but would not execute. This had the effect of loading the resource into cache, and then firing the "load" handlers to let the page know when the resource was completely in cache.

Assuming that the resource was served with proper caching headers, and was in fact in the cache, it could then be executed (nearly) immediately when it was the proper execution order time by re-requesting the same resource via another script-inserted script element with the proper "text/javascript" type value, pulling the resource from the cache and executing it, without another server round-trip.

Of course, the assumption of proper cache headers is a huge one, and not at all reliable. Some recent estimates by performance optimization specialists have suggested as much as 70% of scripts across the internet are not served with proper caching headers, which means that such scripts would be completely ineffective if loaded using this (or a similar) technique. The script resource would end up being loaded completely a second-time, and the "near immediate" execution would obviously be false, and thus race conditions would ensue.

It's important to note at this point that the new <link rel=prefetch> facility has been suggested as a better workaround, but it suffers the same ill-fated assumption of script cacheability. Still others have suggested "new Image().src=..." or the [http://www.phpied.com/preload-then-execute/ <object> preloading trick] suggested by Stoyan Stefanov. Again, these tricks unwisely assume cacheability, for the "preloading" trick to solve the use-case in question.

=== At Risk ===
Currently, there are several large/popular web sites which are either currently (or who intend to soon) use LABjs in such a way as to run afoul of the new Gecko and Webkit behavioral changes with LABjs failing to operate properly. It's important to note that the problems of race conditions can be subtle and hard to detect, and so merely loading up such sites and failing to observe overt failure is not sufficient.

Sites which are known to have LABjs loading techniques in place with currently broken (or susceptible to such breakage in the near future) behavior are:

* [http://twitter.com Twitter]
* [http://zappos.com Zappos]
* [http://vimeo.com Vimeo]
* [http://mefeedia.com MeFeedia]
* [http://blog.getify.com Getify Solutions blog (my blog)]
* [http://flensed.com flensed Flash+JavaScript browser shims (cross-domain Ajax, cross-browser cookies, etc)]

Rather than getting hung up in the syntax of usage in LABjs that is or is not going to break, it's best to just think of the problem this way:

Does a site need to load more than one script, at least one of which comes from a remote domain location (like a CDN), and for which among the scripts there's at least one execution-order dependency among them? If so, then that site is susceptible to the current/future breakage if the HTML spec (and browsers) do not address this use case.

A common example (in use on many sites) of such might be loading:

* jQuery from the CDN
* jQuery-UI from the CDN
* plugins and usage code in one or more local files
* Google Analytics from the Google domain

Note that the emergence of popular script frameworks and their hosting on public CDN's is leading to more and more sites loading scripts from both local and remote locations, and also to loading more files that have dependencies (rather than the practice of concat'ing all files into one file to avoid dependency issues).

Any site which fits a profile like the above, and which might currently (many do), or in the future want to, use a script loader to improve their loading performance, will fail to achieve what they want cross-browser and in a performant way, if the HTML spec (and browsers) do not address the use case.

=== Benefits ===
The benefits of addressing both behaviors directly (without "preloading" tricks and bad assumption reliance) have been implied in the above discussion, but in short are:

a) clear and simplified code for script loaders, which leads to easier use by authors of more pages, which in turn leads to better web performance (as demonstrated clearly by intelligent script loading techniques as compared to just simple <script> tags in HTML markup)

b) full access to either/both of the execution-order behaviors (as the author sees fit), regardless of browser

c) avoiding reliance on bad assumptions (like cacheability) as a sufficient way to address the use-case

=== External Discussions of this Feature ===

* <cite>[http://lists.w3.org/Archives/Public/public-html/2010Oct/0088.html W3C public-html email thread]</cite>

* <cite>[http://www.w3.org/Bugs/Public/show_bug.cgi?id=11295 W3C Bug #11295]</cite>

* <cite>[https://bugzilla.mozilla.org/show_bug.cgi?id=602838 Mozilla Bug #602838]</cite>

* <cite>[https://bugzilla.mozilla.org/show_bug.cgi?id=620852 Mozilla Bug #620852]</cite>

* <cite>[https://bugs.webkit.org/show_bug.cgi?id=50115 Webkit Bug #50115]</cite>

* <cite>[http://hsivonen.iki.fi/script-execution/ HTML5 Script Execution Changes in Firefox 4 Beta 7]</cite>

* <cite>[http://blog.getify.com/2010/10/labjs-w3c-brief-update/ LABjs and W3C... brief update]</cite>

* <cite>[http://blog.getify.com/2010/10/ff4-script-loaders-and-order-preservation/ FF4, script loaders, and order preservation]</cite>

== Proposed Solutions ==

=== My Solution ===
The current proposal most well supported from the email discussion thread, and the one which I feel makes most sense, is described here.

The HTML spec already defines the "async" attribute for parser-inserted script tags, which when set to "true", changes their execution order behavior to be like script-inserted script-elements (in IE/Webkit), which is that they load in parallel and execute "as fast as possible" (ostensibly because the author is expressing no dependencies between multiple such "async"-marked scripts). Parser-inserted script elements without "async" (or with it set to false) behave as before and expected, which is that they load in parallel but execute in order.

However, the HTML spec does not define the "async" property (or any such behavior) for script-inserted script nodes (such as those created by a script loader). Instead, the spec implies that "async=true" like behavior is always true for such script-inserted script elements.

What is proposed is:

a) Script-inserted script elements should have (and respect the value of) an "async" property which is basically identical to the "async" attribute for parser-inserted script elements. That is, script elements with the "async" property set to "true" will behave accordingly, as will script elements with the "async" property set to false.

Essentially, the proposal is to mirror the "async" attribute behavior of parser-inserted script elements as an "async" property on script-inserted script elements. This has the benefit of using an existing facility and extending it (from current spec) in a way that is sensisble and symmetric with its current definition.
<blockquote style="background-color: #EFEFEF">
The scriptgroup or `readyState` alternate proposals allow for dependency management to be done in high-level code. The singular syncrhonized execution queue proposed here introduces artificial dependencies, undermining some of the benefits dynamic script loading provides.
</blockquote>

<blockquote style="background-color: #ccc;">
It's important to note that `async=false` scripts will load in a separate queue from `async=true` scripts. It's not that all scripts will now be forced into this insertion-order-execution queue. An author (or script loader) can chose which queue to put a script loading into based on the needs of the page and the resource. If I have a few scripts that are unrelated to each other and the main page (like Google Analytics, social sharing buttons, etc), I'll load those via `async=true`. For other scripts, where order matters for dependency sake, I'll use `async=false`. I think having both those queues available to high-level code is enough control over loading to serve the majority of use-cases pretty well.
<blockquote style="background-color: #EFEFEF">
If at any point these services begin dynamically loading `async=false` scripts of their own, they will begin blocking. This can lead to unexpected behavior of existing code as third-party libraries and services change. It would seem the specification should provide a means by which this blocking can be isolated to dependencies defined by the author and ordered execution not introduce conditions that allow unrelated libraries to affect this.
</blockquote>
</blockquote>

b) Furthermore, to aid in "feature-detection" of such new behavior, the proposal is to have the default value for the "async" property of script-inserted script elements be "true" (and of course the associated behavior thereof).

There are two major benefits to (b). One is that it provides a way to feature test such new behavior by not just looking for the existence of the "async" property on script elements, but specifically that the default value is "true" (which is opposite of what it would currently/normally be). Secondly, defaulting to "async=true" behavior for script-inserted script elements would preserve the default behavior of IE and Webkit, meaning there'd be less of a chance of breaking existing web content in either of those two browsers.

It's also important to note that there is no implied or requested effect or dependency between script-inserted script elements and parser-inserted script elements -- the two types of scripts would load and execute in entirely separate behavioral sandboxes.

==== Proposal Amendment: Need Attribute/Property Semantic Inconsistency ====
In order to achieve consistency between the semantics of how the parser-inserted script element's `async` attribute and the script-inserted script element's `async` property behave, a slight change needs to be made to the value parsing/interpretation for parser-inserted script elements' `async` attribute.

If a parser-inserted script element has the `async` attribute present, but its value is exactly "false" (or any capitalization thereof), the script element should behave EXACTLY as if no `async` attribute were present.

If the attribute is present and either has no value, or has any other value except "false" (for instance, "true" or "async"), then it should be interpreted to be turning on "async" for that element.

Because it is highly unlikely (and indeed, quite irrational) that any existing web content is doing `async="false"` in HTML markup and yet still expecting "async" behavior to be turned on, it is pretty unlikely that this minor interpretation change will cause backwards-compatibility issues.
[[User:Getify|Getify]] 03:05, 22 December 2010 (UTC)

==== Proposal Amendment: Events ====
In addition to standardizing how scripts load and execute, it's also important to standardize the load and error events, and under what circumstances they fire, etc. Without reliable load/error events, the main proposal is not reliable and is thus unhelpful for the use-case.

A script-inserted script element must fire the "load" event only once, when:

a) immediately after the resource finishes loading, but before parsing/execution, AND

b) the script element loads any non-empty content (that is, it was a successful HTTP request), AND

c) the script element has either loaded from the remote location, or is loaded from the brower cache

Specifically, the script "load" event must come immediately between the script element finishing loading and the script element being parsed/executed. If the script resource successfully loads, nothing should interrupt the sequence of fininshing loading, the "load" event firing, and the script being parsed/executed.

A script-inserted script element must fire the "error" event only once, when:

a) immediately after a loading failure for the resource is detected (that is, an HTTP error received, such as 404, 500, 503, etc).

Either the "load" or "error" event, but not both, will fire, and only once, for every script-inserted script element.

NOTE: "load" and "error" events on script-inserted script elements must fire synchronously to ensure event reliability.

A case may be made for adding the "load" and "error" events as described here to parser-inserted script elements as well.

==== Processing Model ====
Script inserted script elements will have an "async" property that defaults to "true". If the author does not change the value, all such requested script loadings will be in their own "queue" and will default to "as fast as possible" execution behavior. For any script elements that the author sets "async=false", those scripts will load in a separate "queue", and will execute in insertion order only. Again, these two "queues" will operate strictly independent of each other.

==== Processing Model Details (without the event amendment) ====

When a script element node is created, if it is being flagged as parser-inserted, set its force-async flag to false. Otherwise, set its force-async flag to true. (Note that createContextualFragment, innerHTML and XSLTProcessor::transformToFragment-created scripts are not flagged as parser-inserted.) This flag setting happens before any attributes (even parser-set ones) are set on the node.

When a previously-created script element node loses its parser-insertedness, if the element doesn't have the async content attribute, set the force-async flag to true and false otherwise.

When a script element node obtains the async content attribute (via setAttribute, setAttributeNode, setAttributeNS, by the fragment parser or the XSLTProcessor adding the attribute, etc.), set the force-async flag to false. (Note that calling removeAttribute("async") doesn't modify the force-async flag.)

The async IDL attribute must behave as follows:
* Upon setting, set the force-async flag to false and then reflect the async content attribute.
* Upon getting, if the force-async flag is true, return true. Otherwise, reflect the async content attribute.

In step 13. of http://www.whatwg.org/specs/web-apps/current-work/#running-a-script before the case "If the element has a src attribute" add a case:
If the script has a src attribute and the async IDL property getter returns false,
The element must be added to the queue of ordered script-inserted external scripts of the Document of the script element at the time the running a script algorithm started.

The task that the networking task source places on the task queue once the fetching algorithm has completed must run these steps:
# If the queue of ordered script-inserted external scripts is empty or the first script in the queue of ordered script-inserted external scripts has not been fetched yet, abort these steps.
# Execute the first script in the queue of ordered script-inserted external scripts.
# Remove the first script from queue of ordered script-inserted external scripts.
# Goto step #1.

Modify step 5 of http://www.whatwg.org/specs/web-apps/current-work/#the-end to say:
Spin the event loop until the set of scripts that will execute as soon as possible is empty and the queue of ordered script-inserted external scripts is empty.

==== Limitations ====
The two behaviors being identified solve either the case where no dependencies exist, or where a linear dependency chain exists (and which the script elements can be requested to execute in that order). It is possible that some authors have a more complex non-linear dependency chain that they would like to express. This would obviously require a much more complex API and spec change, and since that use-case has not (yet) surfaced as a particularly main-stream request, I believe it would be overengineering to try to address it with this proposed change set.

In addition, it's been duly noted that it's undesirable (and potentially confusing/problematic) to intentionally build in the inconsistency of having the "async" attribute (for parser-inserted scripts) and the "async" property (for script-inserted scripts) have different default values ("false" for the attribute, "true" for the property).

It's also been a point of discussion whether or not such a spec change has enough "carrot" to entice the browser vendors (namely IE and Webkit) to implement the behavior. Moreover, there's been some concern that if the default value for the "async" property were made to be "false" (like the attribute) to be more consistent and conservative, then it would possibly give the perception to IE and Webkit of "losing" some performance to cut out their default "as fast as possible" behavior.

=== Alternate Proposals ===
One early proposal on the email list was to introduce an entirely new property like "ordered" which an author could add to a script-inserted script element to instruct the browser to put it into the queue of execution-order-preserving script loadings. While such a property would address the use case, it introduces another property and thus more complicates the issue. It also fails to address the current spec inconsistency (which is confusing to new comers) that "async" is not a present/respected property in mirror of the attribute of the same name.

Another suggestion was a "waitFor" property that would be added to script elements and would specify a list of one or more DOM id's of other script elements that the current script should "wait for" in terms of execution. Again, this would solve the use case, but in a more complicated way, and there are concerns that it would be too confusing for the normal use-case.

Several suggestions have come in the form of creating explicit "preloading" (similar to <link rel=prefetch>), but as described above, "preloading" to solve this use case is a non-ideal hack and highly susceptible to breakage if the script fails to be sent with proper caching headers.

It's also been suggested that since this type of behavior is somewhat complicated, it may be better to intentionally obfuscate or complicate any such facility in the HTML, so as to make the barrier-to-entry rather high and force users to know what they are doing before doing it.

It's been suggested that "defer" already preserves execution order. However, "defer" is only defined for parser-inserted scripts, and thus is not applicable to the use-case in question from an on-demand point of view. Also, "defer" scripts explicitly way for DOMContentLoaded, even if they're ready to execute sooner. So this is less than desired.

Yet another proposal is a "document.executeScripts()" API, where an author can specify multiple sets of scripts that can load in parallel and it will enforce their execution order. A variation on that same idea was to use the "importScripts" from the Web Workers spec, however "importScripts" is synchronous (undesirable performance wise, obviously). The main downside (besides extra API complication) to "document.executeScripts()" is that there seem to be quite a few script execution properties/behaviors (including "document.currentScript" and charset override) which would have to be duplicated into this API facility.

==== "Script Group" element ====
One recent alternate proposal bears some special consideration, as it seems like it might be a decent option (although certainly more of a radical change for the spec and for browsers to implement). But it has the appearance of being pretty straightforward and semantic for authors to use, perhaps even more so than using "async".

The proposal is to create a new HTML element, called perhaps <scriptGroup>, <collection>, etc. Specifically, this element must be able to be inserted wherever a <script> element can currently be inserted. The "script group" element is intended to signify that all script elements added to it must perserve insertion execution order. This element wouldn't have much (but still some, explained in a moment) meaning in a parser-inserted context, since parser-inserted scripts already preserve order among themselves.

An advantage of the "script group" element would be to give a direct and easy way to attach event listeners ("load" and "error") to the entire group, rather than having to internally track events for each element if all you care about is the final "load" event, for instance. In the case of event handling, the "script group" element would have perhaps some benefit even in parser-inserted (markup) context.

The element would need to have an "id" property, and possibly attributes for "load" and "error" events.

A variation on how to look at this proposal is that a "script group" element could have an attribute/property on it (perhaps called "ordered") which would allow the group to either be order preserved or not. This would make the "script group" element much more useful in the parser-inserted context, as it would sort of be a shortcut to setting "async=true" on all the child script elements.

The "script group" element might look like this:

<scriptGroup id="group1">
<script src="foo.js"></script>
<script src="bar.js"></script>
<script>
somethingInline();
</script>
</scriptGroup>

Or, with the "ordered" attribute to explicitly control ordering behavior for the group:

<scriptGroup id="group1" ordered="true">
<script src="foo.js"></script>
<script src="bar.js"></script>
<script>
somethingInline();
</script>
</scriptGroup>

<scriptGroup id="group2" ordered="false" onload="alldone();">
<script src="baz.js"></script>
<script src="far.js"></script>
<script src="zab.js"></script>
</scriptGroup>

While the "script group" element is definitely more complicated to define and implement, it does have some semantic advantages for authors, and it also would significantly reduce the internal complexity of script loaders like LABjs. It would give authors (either directly or through script loaders) the flexibility to group scripts together into one of the two aforementioned behaviors (execution "as fast as possible" or "in insertion order"), and to easily access both behaviors in the same page.

==== Explicit support for "text/cache" MIME type behavior ====
Yet another alternate proposal has been suggested in the [[Talk:Dynamic_Script_Execution_Order]] thread.

Essentially, the proposal is that <script> tags directly support being declared with a `type` value of "text/cache". The behavior would be that the script resource is fetched, as the load events fired, as normal, but that the script itself would not be executed. Then later, at the desired time, the script in that element could be executed by changing the `type` value from "text/cache" to "text/javascript".

The browser would probably need to keep track (via some internal flag) that the script node is only ever executed once. Also, it's an open question if such a "cached" script node should be able to have its script content modified before execution via the `text` property.
<blockquote style="background-color:#eee">
And does the onload event fire again after the script executes? <br/>
Or only when it's loaded? <br/>
Both seem to violate current `onload` semantics.
[[User:Serverherder|Serverherder]] 20:27, 15 December 2010 (UTC)

<blockquote style="background-color:#ccc">
As far as I'm concerned, I think the "load" event should happen immediately after a script loads, but before it executes, as I spell out in the [[Dynamic_Script_Execution_Order#Proposal_Amendment:_Events|Events proposal ammendment section]]. [[User:Getify|Getify]] 20:33, 15 December 2010 (UTC)
</blockquote>

</blockquote>

==== readyState "preloading" ====
Per the suggestion/comment added to the above [[Dynamic_Script_Execution_Order#Current_Limitations|Current Limitations]] section, it's been suggested that IE's current behavior with respect to the `readyState` property can adequately serve the use-case in question. This alternate proposal is very similar in spirit to the [[Dynamic_Script_Execution_Order#Explicit_support_for_.22text.2Fcache.22_MIME_type_behavior|previous section on explicit support for "text/cache"]] mime-type value.

The idea is that IE will begin fetching into the cache a script resource as soon as the `src` attribute of the dynamic script element is set. But IE will not execute the script (even if it finishes loading) until the script element is added to the DOM. However, the `readyState` property of the element, combined with the `onreadystatechange` handler listening for changes, can detect when the script has finished loading, by receiving the "loaded" value.

In this way, a script loader could "preload" a set of scripts all in parallel, but control their execution order by delaying the appending of the element to the DOM until execution is desired.

'''Update''' [[User:Getify|Getify]] 14:10, 20 December 2010 (UTC)

[http://www.w3.org/TR/html5/scripting-1.html#running-a-script HTML Spec, 4.3.1, 'Running a script' algorithm]

Specifically, in step 12 (which is about fetching a `src` URL):

<blockquote>
For performance reasons, user agents may start fetching the script as soon as the attribute is set, instead, in the hope that the element will be inserted into the document. Either way, once the element is inserted into the document, the load must have started. If the UA performs such prefetching, but the element is never inserted in the document, or the src attribute is dynamically changed, then the user agent will not execute the script, and the fetching process will have been effectively wasted.
</blockquote>

This seems to be the spec stating that browsers may do what IE's behavior on scripts does, which is to start fetching the resource once the `src` property is set, but not execute it until the script element is inserted into the DOM.

It would seem then that browsers could/should be petitioned to consider implementing this suggestion, perhaps taking the `readyState` implementation from IE as guidance. While I'm still not sure that this would be my preferred method of solving the overall use-case in discussion on this page, it would be an option for such, and it would also help other use-cases, such as those being discussed in this W3C public-html thread:

[http://lists.w3.org/Archives/Public/public-html/2010Dec/0174.html Need to: "preload" CSS and JS]

==== Do nothing and encourage vendors implement the existing suggestion ====
As noted by Getify above, the spec all ready makes the suggestion that a script's SRC attribute be fetched immediately upon assignment.

[http://www.w3.org/TR/html5/scripting-1.html#running-a-script HTML Spec, 4.3.1, 'Running a script' algorithm]

While not explicit, it seems the specification all ready deals with the use-case this is hoping to achieve: It makes parallel loading scripts '''optional'''. Execution order can all ready be handled by loaders using onload-chaining. Therefore, parallel loading can be achieved, but only in browsers that have chosen to implement the suggestion.

Given this, the discussion can shift to:
# Should the suggestion be changed to a mandate?
# Should the specification include a way to '''force''' parallel loading?
# Should we be petitioning vendors, not the the W3C, to implement the existing suggestion?

[[Category:Feature Request|Dynamic Script Execution Order]]

Talk:Dynamic Script Execution Order

2010-12-16T01:52:49Z

Serverherder: /* RequireJS order support */

Dynamic Script Execution Order

2010-12-15T20:27:22Z

Serverherder: /* Explicit support for "text/cache" MIME type behavior */

This page is intended to formalize the discussion around an important but currently underserved use-case (in both spec and various browser implementations): the need for a dynamic script loading facility that can download resources in parallel but ensure that they execute serially in insertion order, for dependency reasons.

A long email thread on the W3C public-html list, which began [http://lists.w3.org/Archives/Public/public-html/2010Oct/0088.html here] and for which a recent message is [http://lists.w3.org/Archives/Public/public-html/2010Oct/0415.html here], has been discussing this problem, but the email thread is becoming unruly and hard to track, so this wiki page will now be the official location to discuss the topic.

Briefly, this issue has arisen because recent "nightlies" changes in both Mozilla Gecko and Webkit have broken the ability for script-loaders like [http://labjs.com LABjs] to be able to download scripts in parallel but ensure their execution order. As a result of the discussion, it's become apparent that both the spec for, and various current browser implementations around, dynamic script loading is incomplete in addressing this use case, and that some change needs to occur.

There is one main proposal that has surfaced from the discussions, with several other alternatives having been discussed. This page will try to distill the long email thread down and clearly present the main proposal, objections, and alternative suggestions.

Please feel free to join the discussion of this topic in the [[Talk:Dynamic_Script_Execution_Order]] area.

== Use Case Description ==
Script tags/elements can either:

a) appear in the HTML markup ("parser-inserted"), OR

b) be dynamically appended to the DOM using document.createElement() ("script-inserted")

Parser-inserted script tags, up until recent browser versions, had the undesirable performance behavior of loading and executing serially, blocking everything else while doing so. Recently, many browsers have improved the situation by loading the scripts in parallel, but still executing them in order.

On-demand (or dynamic) script loading has emerged in recent years for a variety of different reasons, most notably the performance improvements to address such concerns. It is desired by many different scenarios to be able to download scripts to a page completely independently of the loading of the rest of a page's resources, or even well after a page has finished loading ("on-demand").

Recent additions to HTML spec such as "defer" and "async" were intended to address the use-case for parser-inserted script elements, but their behaviors have been unhelpful for the on-demand loading use-case (script-inserted script elements).

Thus, script loaders (like [http://labjs.com LABjs]) were developed to give page authors an easy way to specify one or more scripts to load (regardless of when in the life-time of the page that loading is requested), and for as many of them as possible to load in parallel, and for those scripts to be loadable from any local or remote domain location, and for the script loader to be able to control the execution order (if the usage of the script loader's API expresses the need to) to preserve dependencies between the scripts.

Sometimes, dynamic script loading is used to load totally independent scripts, and thus "as fast as possible" execution is desired. Other times (and possibly more frequently), multiple scripts are loaded with some dependencies among them, requiring them to execute in a certain order.

What is needed is some facility by which a script loader can express that dynamic script loading either does or does not need execution order preserved among the queue of requested script loadings.

=== Current Limitations ===
Unfortunately, browser behavior around script-inserted script elements and their loading and execution behavior is splintered. There are, at present, two main camps of behavior:

a) in IE and Webkit (including Chrome), the default behavior for script-inserted script elements is for them all to execute in "as fast as possible" mode, meaning there's no guarantee about ordering. This effectively makes on-demand (dynamic) script loading impossible to work in parallel-mode if the resources in question have dependencies -- the only straight-forward way to handle things is to load each file and execute, serially, losing the parallel loading performance benefits.
<blockquote style="background-color: #EEEEEE">
I'm not sure if this is the case.

IE will start fetching resources without execution simply by setting the src attribute. Scripts will not execute, however, until they are added to the document. Since IE supports the readyState attribute and readystatechange event, it's possible to load scripts in parallel and execute them in order without resorting to invalid type attribute hack-ery.

<pre style="background-color:white" lang="javascript">
script= document.createElement("SCRIPT");
script.onreadystatechange= function(){
if(this.readyState == 'loaded')
/*
Network fetch is now complete, following
triggers synchronous execution.
*/
document.body.appendChild(this);
else if(this.readyState == "complete")
this.onreadystatechange= null;
}
script.src= "foo.js";
/* Network fetching begins now */
</pre>
</blockquote>

<blockquote style="background-color: #ccc">
I've experimented with such things heavily in the past, and I'm fairly suspicious that this is not reliable across various versions of IE (6-9), nor does it work reliably the same depending on if an element is already in the browser cache or not. I'm not 100% certain that what you suggest is flawed, but I have a strong hunch that it can be shown to have some holes in it for IE loading. I will try to create some test cases to prove or disprove.
<blockquote style="background-color: #EEEEEE">
When loading a script that is in the cache, IE requires the event handler be installed prior to setting the `src` attribute. Otherwise the element's transition to the "loaded" state will be missed. IE routinely "skips" ready state transitions when cached scripts are immediately inserted into the DOM so suspicion is understandable; however, delayed insertion works around this "problem". The script above has been tested in IE6-8 with scripts in a variety of caching states and found to work correctly.
</blockquote>

Moreover, you're suggesting something that is AFAIK only IE right now, and definitely appears to not be standardized. In the same way that I'm hesitant to continue pinning loading behavior on hacks like the invalid type attribute value, I wouldn't want to approach loading with this technique (even if it were proven reliable on all IE's under all caching circumstances) unless it was a serious proposal to the W3C to have this technique be the new standard (as opposed to the current proposal, as implemented by Mozilla and Webkit now).
<blockquote style="background-color: #EEEEEE">
I think you're right: Only IE impelements this event and property on script elements. The readystatechange event, however, is widely understood due to the XmlHttpRequest implementation and `readyState` property has been added to the `document` in WebKit, Mozilla and IE.
</blockquote>

That having been said, I think this is at least a viable candidate for "Alternate Proposals" and deserves to be listed as such. As always, I welcome input from the community on all the ideas presented here, including this one. But, since the main proposal (async=false) is already being implemented by at least two major browsers, I'm not sure if the tide will be changed or not.

</blockquote>

<blockquote style="background-color:#ddd;">
Also, the suggestion of handling the "preload" and deferred execution via the script tag's `readyState` property is very similar in spirit to the suggestion that was made to explicitly support [[Dynamic_Script_Execution_Order#Explicit_support_for_.22text.2Fcache.22_MIME_type_behavior|preloading into cache without execution]]. As I said, either of those two approaches might work, but they both put more of the onus of complexity in managing multiple dependencies on the high-level code (author, script loader, etc). I'm more in favor of this functionality being explicitly built-in natively into the queues. As always, I welcome comments to any side of this discussion.

[[User:Getify|Getify]] 18:35, 15 December 2010 (UTC)
</blockquote>

b) in Gecko and Opera, the default behavior for script-inserted script elements is for them all to load in parallel, but execute serially in insertion order. Technically, this makes it impossible to dynamically load independent script elements and have them execute in "as fast as possible" mode.

As described above, both behaviors are desirable under different circumstances, but each of the two camps provides only one behavior, and no way to straightforwardly achieve the other. This obviously creates a big nightmare interoperability-wise when trying to provide a general script loader cross-browser.

Since it is observed that the behavior in (a) is more detrimental (race-condition wise) for the case where dependencies exist, script loaders like LABjs had to find some way around this problem while still attempting the best possible parallel loading performance. However, the trick used is hacky and not completely reliable -- yet it is the best way to solve the use-case in <s>IE and </s>Webkit.

For Gecko/Opera, the concession was just (silently) made that the lesser-common use case of "as fast as possible" wasn't possible, but degraded fine to "insertion order execution", while keeping the parallel loading benefits.

<blockquote style="background-color: #EEEEEE">
Gecko's strict execution order creates dependencies between scripts which are unrelated and prevents the ability mitigate the impact of server outages / network latency. This is exacerbated by the fact that Gecko, unlike IE and WebKit, provides no mechanism to <b>remove</b> scripts from the execution queue.

Consider the case where JSONP is used to provide auto-completion. The user types "hello" and the JSONP request is made; however, the "currently" loading script is out-of-date as soon as the user modifies his search to "hello world". Gecko's algorithm requires the out-of-date request load and execute before the second request.
</blockquote>

Recently, Gecko landed a [http://hg.mozilla.org/mozilla-central/rev/a60414d076b5 patch] to the trunk that stopped Gecko's existing behavior of preserving execution order, making script-inserted script elements now execute in "as fast as possible" mode similiar to IE/Webkit. Unfortunately, the "workaround" used in IE/Webkit (described in the next section) for dealing with parallel loading and execution-order dependencies does not work in Gecko, which means presently the use-case in question is now broken in Gecko trunk/FF4 nightlies.

Moreover, Webkit recently landed a [http://trac.webkit.org/changeset/67245 patch] to the trunk that stopped Webkit's non-standard but long-held behavior (also used in the "workaround" described in the next section) of loading into cache script resources with an unrecognized "type" value, but silently not executing them. This behvaior (while hacky) is central to being able to address the use-case in question in Webkit, so at present, Webkit nightlies are now also entirely broken on the use-case (though in a different way than Gecko).

Both the Gecko change and the Webkit change are well-intentioned, as they are bringing the respective browser more in line with the HTML spec. However, what's really been demonstrated is that the HTML spec is not properly handling this use-case, and so the goal is not to address the browser issues raised with more awkward hacks, but to address the shortcomings of the spec first, and then encourage all browsers to adhere to such.

<blockquote style="background-color: #EEEEEE">
Considering Internet Explorer's readyState implementation provides a means of both parallel loading and preserving execution order can be achieved, perhaps its "readyState" property and onreadystatechange event should be included.
</blockquote>

=== Current Usage and Workarounds ===
To work around the limitation in IE/Webkit(prior to the above noted patch) of not being able to rely on script order execution for parallel loaded scripts, a "preloading" trick was developed. This trick relied on non-standard (but long-held) behavior in these browsers that a script-inserted script element with an unrecognized "type" value (such as "script/cache") would be fetched/loaded, but would not execute. This had the effect of loading the resource into cache, and then firing the "load" handlers to let the page know when the resource was completely in cache.

Assuming that the resource was served with proper caching headers, and was in fact in the cache, it could then be executed (nearly) immediately when it was the proper execution order time by re-requesting the same resource via another script-inserted script element with the proper "text/javascript" type value, pulling the resource from the cache and executing it, without another server round-trip.

Of course, the assumption of proper cache headers is a huge one, and not at all reliable. Some recent estimates by performance optimization specialists have suggested as much as 70% of scripts across the internet are not served with proper caching headers, which means that such scripts would be completely ineffective if loaded using this (or a similar) technique. The script resource would end up being loaded completely a second-time, and the "near immediate" execution would obviously be false, and thus race conditions would ensue.

It's important to note at this point that the new <link rel=prefetch> facility has been suggested as a better workaround, but it suffers the same ill-fated assumption of script cacheability. Still others have suggested "new Image().src=..." or the [http://www.phpied.com/preload-then-execute/ <object> preloading trick] suggested by Stoyan Stefanov. Again, these tricks unwisely assume cacheability, for the "preloading" trick to solve the use-case in question.

=== At Risk ===
Currently, there are several large/popular web sites which are either currently (or who intend to soon) use LABjs in such a way as to run afoul of the new Gecko and Webkit behavioral changes with LABjs failing to operate properly. It's important to note that the problems of race conditions can be subtle and hard to detect, and so merely loading up such sites and failing to observe overt failure is not sufficient.

Sites which are known to have LABjs loading techniques in place with currently broken (or susceptible to such breakage in the near future) behavior are:

* [http://twitter.com Twitter]
* [http://zappos.com Zappos]
* [http://vimeo.com Vimeo]
* [http://mefeedia.com MeFeedia]
* [http://blog.getify.com Getify Solutions blog (my blog)]
* [http://flensed.com flensed Flash+JavaScript browser shims (cross-domain Ajax, cross-browser cookies, etc)]

Rather than getting hung up in the syntax of usage in LABjs that is or is not going to break, it's best to just think of the problem this way:

Does a site need to load more than one script, at least one of which comes from a remote domain location (like a CDN), and for which among the scripts there's at least one execution-order dependency among them? If so, then that site is susceptible to the current/future breakage if the HTML spec (and browsers) do not address this use case.

A common example (in use on many sites) of such might be loading:

* jQuery from the CDN
* jQuery-UI from the CDN
* plugins and usage code in one or more local files
* Google Analytics from the Google domain

Note that the emergence of popular script frameworks and their hosting on public CDN's is leading to more and more sites loading scripts from both local and remote locations, and also to loading more files that have dependencies (rather than the practice of concat'ing all files into one file to avoid dependency issues).

Any site which fits a profile like the above, and which might currently (many do), or in the future want to, use a script loader to improve their loading performance, will fail to achieve what they want cross-browser and in a performant way, if the HTML spec (and browsers) do not address the use case.

=== Benefits ===
The benefits of addressing both behaviors directly (without "preloading" tricks and bad assumption reliance) have been implied in the above discussion, but in short are:

a) clear and simplified code for script loaders, which leads to easier use by authors of more pages, which in turn leads to better web performance (as demonstrated clearly by intelligent script loading techniques as compared to just simple <script> tags in HTML markup)

b) full access to either/both of the execution-order behaviors (as the author sees fit), regardless of browser

c) avoiding reliance on bad assumptions (like cacheability) as a sufficient way to address the use-case

=== External Discussions of this Feature ===

* <cite>[http://lists.w3.org/Archives/Public/public-html/2010Oct/0088.html W3C public-html email thread]</cite>

* <cite>[http://www.w3.org/Bugs/Public/show_bug.cgi?id=11295 W3C Bug #11295]</cite>

* <cite>[https://bugzilla.mozilla.org/show_bug.cgi?id=602838 Mozilla Bug #602838]</cite>

* <cite>[https://bugs.webkit.org/show_bug.cgi?id=50115 Webkit Bug #50115]</cite>

* <cite>[http://hsivonen.iki.fi/script-execution/ HTML5 Script Execution Changes in Firefox 4 Beta 7]</cite>

* <cite>[http://blog.getify.com/2010/10/labjs-w3c-brief-update/ LABjs and W3C... brief update]</cite>

* <cite>[http://blog.getify.com/2010/10/ff4-script-loaders-and-order-preservation/ FF4, script loaders, and order preservation]</cite>

== Proposed Solutions ==

=== My Solution ===
The current proposal most well supported from the email discussion thread, and the one which I feel makes most sense, is described here.

The HTML spec already defines the "async" attribute for parser-inserted script tags, which when set to "true", changes their execution order behavior to be like script-inserted script-elements (in IE/Webkit), which is that they load in parallel and execute "as fast as possible" (ostensibly because the author is expressing no dependencies between multiple such "async"-marked scripts). Parser-inserted script elements without "async" (or with it set to false) behave as before and expected, which is that they load in parallel but execute in order.

However, the HTML spec does not define the "async" property (or any such behavior) for script-inserted script nodes (such as those created by a script loader). Instead, the spec implies that "async=true" like behavior is always true for such script-inserted script elements.

What is proposed is:

a) Script-inserted script elements should have (and respect the value of) an "async" property which is basically identical to the "async" attribute for parser-inserted script elements. That is, script elements with the "async" property set to "true" will behave accordingly, as will script elements with the "async" property set to false.

Essentially, the proposal is to mirror the "async" attribute behavior of parser-inserted script elements as an "async" property on script-inserted script elements. This has the benefit of using an existing facility and extending it (from current spec) in a way that is sensisble and symmetric with its current definition.
<blockquote style="background-color: #EFEFEF">
The scriptgroup or `readyState` alternate proposals allow for dependency management to be done in high-level code. The singular syncrhonized execution queue proposed here introduces artificial dependencies, undermining some of the benefits dynamic script loading provides.
</blockquote>

<blockquote style="background-color: #ccc;">
It's important to note that `async=false` scripts will load in a separate queue from `async=true` scripts. It's not that all scripts will now be forced into this insertion-order-execution queue. An author (or script loader) can chose which queue to put a script loading into based on the needs of the page and the resource. If I have a few scripts that are unrelated to each other and the main page (like Google Analytics, social sharing buttons, etc), I'll load those via `async=true`. For other scripts, where order matters for dependency sake, I'll use `async=false`. I think having both those queues available to high-level code is enough control over loading to serve the majority of use-cases pretty well.
<blockquote style="background-color: #EFEFEF">
If at any point these services begin dynamically loading `async=false` scripts of their own, they will begin blocking. This can lead to unexpected behavior of existing code as third-party libraries and services change. It would seem the specification should provide a means by which this blocking can be isolated to dependencies defined by the author and ordered execution not introduce conditions that allow unrelated libraries to affect this.
</blockquote>
</blockquote>

b) Furthermore, to aid in "feature-detection" of such new behavior, the proposal is to have the default value for the "async" property of script-inserted script elements be "true" (and of course the associated behavior thereof).

There are two major benefits to (b). One is that it provides a way to feature test such new behavior by not just looking for the existence of the "async" property on script elements, but specifically that the default value is "true" (which is opposite of what it would currently/normally be). Secondly, defaulting to "async=true" behavior for script-inserted script elements would preserve the default behavior of IE and Webkit, meaning there'd be less of a chance of breaking existing web content in either of those two browsers.

It's also important to note that there is no implied or requested effect or dependency between script-inserted script elements and parser-inserted script elements -- the two types of scripts would load and execute in entirely separate behavioral sandboxes.

==== Proposal Amendment: Events ====
In addition to standardizing how scripts load and execute, it's also important to standardize the load and error events, and under what circumstances they fire, etc. Without reliable load/error events, the main proposal is not reliable and is thus unhelpful for the use-case.

A script-inserted script element must fire the "load" event only once, when:

a) immediately after the resource finishes loading, but before parsing/execution, AND

b) the script element loads any non-empty content (that is, it was a successful HTTP request), AND

c) the script element has either loaded from the remote location, or is loaded from the brower cache

Specifically, the script "load" event must come immediately between the script element finishing loading and the script element being parsed/executed. If the script resource successfully loads, nothing should interrupt the sequence of fininshing loading, the "load" event firing, and the script being parsed/executed.

A script-inserted script element must fire the "error" event only once, when:

a) immediately after a loading failure for the resource is detected (that is, an HTTP error received, such as 404, 500, 503, etc).

Either the "load" or "error" event, but not both, will fire, and only once, for every script-inserted script element.

NOTE: "load" and "error" events on script-inserted script elements must fire synchronously to ensure event reliability.

A case may be made for adding the "load" and "error" events as described here to parser-inserted script elements as well.

==== Processing Model ====
Script inserted script elements will have an "async" property that defaults to "true". If the author does not change the value, all such requested script loadings will be in their own "queue" and will default to "as fast as possible" execution behavior. For any script elements that the author sets "async=false", those scripts will load in a separate "queue", and will execute in insertion order only. Again, these two "queues" will operate strictly independent of each other.

==== Processing Model Details (without the event amendment) ====

When a script element node is created, if it is being flagged as parser-inserted, set its force-async flag to false. Otherwise, set its force-async flag to true. (Note that createContextualFragment, innerHTML and XSLTProcessor::transformToFragment-created scripts are not flagged as parser-inserted.) This flag setting happens before any attributes (even parser-set ones) are set on the node.

When a previously-created script element node loses its parser-insertedness, if the element doesn't have the async content attribute, set the force-async flag to true and false otherwise.

When a script element node obtains the async content attribute (via setAttribute, setAttributeNode, setAttributeNS, by the fragment parser or the XSLTProcessor adding the attribute, etc.), set the force-async flag to false. (Note that calling removeAttribute("async") doesn't modify the force-async flag.)

The async IDL attribute must behave as follows:
* Upon setting, set the force-async flag to false and then reflect the async content attribute.
* Upon getting, if the force-async flag is true, return true. Otherwise, reflect the async content attribute.

In step 13. of http://www.whatwg.org/specs/web-apps/current-work/#running-a-script before the case "If the element has a src attribute" add a case:
If the script has a src attribute and the async IDL property getter returns false,
The element must be added to the queue of ordered script-inserted external scripts of the Document of the script element at the time the running a script algorithm started.

The task that the networking task source places on the task queue once the fetching algorithm has completed must run these steps:
# If the queue of ordered script-inserted external scripts is empty or the first script in the queue of ordered script-inserted external scripts has not been fetched yet, abort these steps.
# Execute the first script in the queue of ordered script-inserted external scripts.
# Remove the first script from queue of ordered script-inserted external scripts.
# Goto step #1.

Modify step 5 of http://www.whatwg.org/specs/web-apps/current-work/#the-end to say:
Spin the event loop until the set of scripts that will execute as soon as possible is empty and the queue of ordered script-inserted external scripts is empty.

==== Limitations ====
The two behaviors being identified solve either the case where no dependencies exist, or where a linear dependency chain exists (and which the script elements can be requested to execute in that order). It is possible that some authors have a more complex non-linear dependency chain that they would like to express. This would obviously require a much more complex API and spec change, and since that use-case has not (yet) surfaced as a particularly main-stream request, I believe it would be overengineering to try to address it with this proposed change set.

In addition, it's been duly noted that it's undesirable (and potentially confusing/problematic) to intentionally build in the inconsistency of having the "async" attribute (for parser-inserted scripts) and the "async" property (for script-inserted scripts) have different default values ("false" for the attribute, "true" for the property).

It's also been a point of discussion whether or not such a spec change has enough "carrot" to entice the browser vendors (namely IE and Webkit) to implement the behavior. Moreover, there's been some concern that if the default value for the "async" property were made to be "false" (like the attribute) to be more consistent and conservative, then it would possibly give the perception to IE and Webkit of "losing" some performance to cut out their default "as fast as possible" behavior.

=== Alternate Proposals ===
One early proposal on the email list was to introduce an entirely new property like "ordered" which an author could add to a script-inserted script element to instruct the browser to put it into the queue of execution-order-preserving script loadings. While such a property would address the use case, it introduces another property and thus more complicates the issue. It also fails to address the current spec inconsistency (which is confusing to new comers) that "async" is not a present/respected property in mirror of the attribute of the same name.

Another suggestion was a "waitFor" property that would be added to script elements and would specify a list of one or more DOM id's of other script elements that the current script should "wait for" in terms of execution. Again, this would solve the use case, but in a more complicated way, and there are concerns that it would be too confusing for the normal use-case.

Several suggestions have come in the form of creating explicit "preloading" (similar to <link rel=prefetch>), but as described above, "preloading" to solve this use case is a non-ideal hack and highly susceptible to breakage if the script fails to be sent with proper caching headers.

It's also been suggested that since this type of behavior is somewhat complicated, it may be better to intentionally obfuscate or complicate any such facility in the HTML, so as to make the barrier-to-entry rather high and force users to know what they are doing before doing it.

It's been suggested that "defer" already preserves execution order. However, "defer" is only defined for parser-inserted scripts, and thus is not applicable to the use-case in question from an on-demand point of view. Also, "defer" scripts explicitly way for DOMContentLoaded, even if they're ready to execute sooner. So this is less than desired.

Yet another proposal is a "document.executeScripts()" API, where an author can specify multiple sets of scripts that can load in parallel and it will enforce their execution order. A variation on that same idea was to use the "importScripts" from the Web Workers spec, however "importScripts" is synchronous (undesirable performance wise, obviously). The main downside (besides extra API complication) to "document.executeScripts()" is that there seem to be quite a few script execution properties/behaviors (including "document.currentScript" and charset override) which would have to be duplicated into this API facility.

==== "Script Group" element ====
One recent alternate proposal bears some special consideration, as it seems like it might be a decent option (although certainly more of a radical change for the spec and for browsers to implement). But it has the appearance of being pretty straightforward and semantic for authors to use, perhaps even more so than using "async".

The proposal is to create a new HTML element, called perhaps <scriptGroup>, <collection>, etc. Specifically, this element must be able to be inserted wherever a <script> element can currently be inserted. The "script group" element is intended to signify that all script elements added to it must perserve insertion execution order. This element wouldn't have much (but still some, explained in a moment) meaning in a parser-inserted context, since parser-inserted scripts already preserve order among themselves.

An advantage of the "script group" element would be to give a direct and easy way to attach event listeners ("load" and "error") to the entire group, rather than having to internally track events for each element if all you care about is the final "load" event, for instance. In the case of event handling, the "script group" element would have perhaps some benefit even in parser-inserted (markup) context.

The element would need to have an "id" property, and possibly attributes for "load" and "error" events.

A variation on how to look at this proposal is that a "script group" element could have an attribute/property on it (perhaps called "ordered") which would allow the group to either be order preserved or not. This would make the "script group" element much more useful in the parser-inserted context, as it would sort of be a shortcut to setting "async=true" on all the child script elements.

The "script group" element might look like this:

<scriptGroup id="group1">
<script src="foo.js"></script>
<script src="bar.js"></script>
<script>
somethingInline();
</script>
</scriptGroup>

Or, with the "ordered" attribute to explicitly control ordering behavior for the group:

<scriptGroup id="group1" ordered="true">
<script src="foo.js"></script>
<script src="bar.js"></script>
<script>
somethingInline();
</script>
</scriptGroup>

<scriptGroup id="group2" ordered="false" onload="alldone();">
<script src="baz.js"></script>
<script src="far.js"></script>
<script src="zab.js"></script>
</scriptGroup>

While the "script group" element is definitely more complicated to define and implement, it does have some semantic advantages for authors, and it also would significantly reduce the internal complexity of script loaders like LABjs. It would give authors (either directly or through script loaders) the flexibility to group scripts together into one of the two aforementioned behaviors (execution "as fast as possible" or "in insertion order"), and to easily access both behaviors in the same page.

==== Explicit support for "text/cache" MIME type behavior ====
Yet another alternate proposal has been suggested in the [[Talk:Dynamic_Script_Execution_Order]] thread.

Essentially, the proposal is that <script> tags directly support being declared with a `type` value of "text/cache". The behavior would be that the script resource is fetched, as the load events fired, as normal, but that the script itself would not be executed. Then later, at the desired time, the script in that element could be executed by changing the `type` value from "text/cache" to "text/javascript".

The browser would probably need to keep track (via some internal flag) that the script node is only ever executed once. Also, it's an open question if such a "cached" script node should be able to have its script content modified before execution via the `text` property.
<blockquote style="background-color:#eee">
And does the onload event fire again after the script executes? <br/>
Or only when it's loaded? <br/>
Both seem to violate current `onload` semantics.
[[User:Serverherder|Serverherder]] 20:27, 15 December 2010 (UTC)
</blockquote>

==== readyState "preloading" ====
Per the suggestion/comment added to the above [[Dynamic_Script_Execution_Order#Current_Limitations|Current Limitations]] section, it's been suggested that IE's current behavior with respect to the `readyState` property can adequately serve the use-case in question. This alternate proposal is very similar in spirit to the [[Dynamic_Script_Execution_Order#Explicit_support_for_.22text.2Fcache.22_MIME_type_behavior|previous section on explicit support for "text/cache"]] mime-type value.

The idea is that IE will begin fetching into the cache a script resource as soon as the `src` attribute of the dynamic script element is set. But IE will not execute the script (even if it finishes loading) until the script element is added to the DOM. However, the `readyState` property of the element, combined with the `onreadystatechange` handler listening for changes, can detect when the script has finished loading, by receiving the "loaded" value.

In this way, a script loader could "preload" a set of scripts all in parallel, but control their execution order by delaying the appending of the element to the DOM until execution is desired.

[[Category:Feature Request|Dynamic Script Execution Order]]

Talk:Dynamic Script Execution Order

2010-12-15T19:51:08Z

Serverherder: /* RequireJS order support */

Talk:Dynamic Script Execution Order

2010-12-15T19:44:57Z

Serverherder: /* RequireJS order support */

Talk:Dynamic Script Execution Order

2010-12-15T19:30:56Z

Serverherder: /* Response */

Talk:Dynamic Script Execution Order

2010-12-15T19:23:37Z

Serverherder: /* Response */

Talk:Dynamic Script Execution Order

2010-12-15T19:10:08Z

Serverherder: /* "text/cache" response */

User:Serverherder

2010-12-15T18:57:06Z

Serverherder: Created page with '[http://digital-fulcrum.com/ Digital Fulcrum]'

[http://digital-fulcrum.com/ Digital Fulcrum]

Dynamic Script Execution Order

2010-12-15T18:49:29Z

Serverherder: /* My Solution */

This page is intended to formalize the discussion around an important but currently underserved use-case (in both spec and various browser implementations): the need for a dynamic script loading facility that can download resources in parallel but ensure that they execute serially in insertion order, for dependency reasons.

A long email thread on the W3C public-html list, which began [http://lists.w3.org/Archives/Public/public-html/2010Oct/0088.html here] and for which a recent message is [http://lists.w3.org/Archives/Public/public-html/2010Oct/0415.html here], has been discussing this problem, but the email thread is becoming unruly and hard to track, so this wiki page will now be the official location to discuss the topic.

Briefly, this issue has arisen because recent "nightlies" changes in both Mozilla Gecko and Webkit have broken the ability for script-loaders like [http://labjs.com LABjs] to be able to download scripts in parallel but ensure their execution order. As a result of the discussion, it's become apparent that both the spec for, and various current browser implementations around, dynamic script loading is incomplete in addressing this use case, and that some change needs to occur.

There is one main proposal that has surfaced from the discussions, with several other alternatives having been discussed. This page will try to distill the long email thread down and clearly present the main proposal, objections, and alternative suggestions.

Please feel free to join the discussion of this topic in the [[Talk:Dynamic_Script_Execution_Order]] area.

== Use Case Description ==
Script tags/elements can either:

a) appear in the HTML markup ("parser-inserted"), OR

b) be dynamically appended to the DOM using document.createElement() ("script-inserted")

Parser-inserted script tags, up until recent browser versions, had the undesirable performance behavior of loading and executing serially, blocking everything else while doing so. Recently, many browsers have improved the situation by loading the scripts in parallel, but still executing them in order.

On-demand (or dynamic) script loading has emerged in recent years for a variety of different reasons, most notably the performance improvements to address such concerns. It is desired by many different scenarios to be able to download scripts to a page completely independently of the loading of the rest of a page's resources, or even well after a page has finished loading ("on-demand").

Recent additions to HTML spec such as "defer" and "async" were intended to address the use-case for parser-inserted script elements, but their behaviors have been unhelpful for the on-demand loading use-case (script-inserted script elements).

Thus, script loaders (like [http://labjs.com LABjs]) were developed to give page authors an easy way to specify one or more scripts to load (regardless of when in the life-time of the page that loading is requested), and for as many of them as possible to load in parallel, and for those scripts to be loadable from any local or remote domain location, and for the script loader to be able to control the execution order (if the usage of the script loader's API expresses the need to) to preserve dependencies between the scripts.

Sometimes, dynamic script loading is used to load totally independent scripts, and thus "as fast as possible" execution is desired. Other times (and possibly more frequently), multiple scripts are loaded with some dependencies among them, requiring them to execute in a certain order.

What is needed is some facility by which a script loader can express that dynamic script loading either does or does not need execution order preserved among the queue of requested script loadings.

=== Current Limitations ===
Unfortunately, browser behavior around script-inserted script elements and their loading and execution behavior is splintered. There are, at present, two main camps of behavior:

a) in IE and Webkit (including Chrome), the default behavior for script-inserted script elements is for them all to execute in "as fast as possible" mode, meaning there's no guarantee about ordering. This effectively makes on-demand (dynamic) script loading impossible to work in parallel-mode if the resources in question have dependencies -- the only straight-forward way to handle things is to load each file and execute, serially, losing the parallel loading performance benefits.
<blockquote style="background-color: #EEEEEE">
I'm not sure if this is the case.

IE will start fetching resources without execution simply by setting the src attribute. Scripts will not execute, however, until they are added to the document. Since IE supports the readyState attribute and readystatechange event, it's possible to load scripts in parallel and execute them in order without resorting to invalid type attribute hack-ery.

<pre style="background-color:white" lang="javascript">
script= document.createElement("SCRIPT");
script.onreadystatechange= function(){
if(this.readyState == 'loaded')
/*
Network fetch is now complete, following
triggers synchronous execution.
*/
document.body.appendChild(this);
else if(this.readyState == "complete")
this.onreadystatechange= null;
}
script.src= "foo.js";
/* Network fetching begins now */
</pre>
</blockquote>

<blockquote style="background-color: #ccc">
I've experimented with such things heavily in the past, and I'm fairly suspicious that this is not reliable across various versions of IE (6-9), nor does it work reliably the same depending on if an element is already in the browser cache or not. I'm not 100% certain that what you suggest is flawed, but I have a strong hunch that it can be shown to have some holes in it for IE loading. I will try to create some test cases to prove or disprove.
<blockquote style="background-color: #EEEEEE">
When loading a script that is in the cache, IE requires the event handler be installed prior to setting the `src` attribute. Otherwise the element's transition to the "loaded" state will be missed. IE routinely "skips" ready state transitions when cached scripts are immediately inserted into the DOM so suspicion is understandable; however, delayed insertion works around this "problem". The script above has been tested in IE6-8 with scripts in a variety of caching states and found to work correctly.
</blockquote>

Moreover, you're suggesting something that is AFAIK only IE right now, and definitely appears to not be standardized. In the same way that I'm hesitant to continue pinning loading behavior on hacks like the invalid type attribute value, I wouldn't want to approach loading with this technique (even if it were proven reliable on all IE's under all caching circumstances) unless it was a serious proposal to the W3C to have this technique be the new standard (as opposed to the current proposal, as implemented by Mozilla and Webkit now).
<blockquote style="background-color: #EEEEEE">
I think you're right: Only IE impelements this event and property on script elements. The readystatechange event, however, is widely understood due to the XmlHttpRequest implementation and `readyState` property has been added to the `document` in WebKit, Mozilla and IE.
</blockquote>

That having been said, I think this is at least a viable candidate for "Alternate Proposals" and deserves to be listed as such. As always, I welcome input from the community on all the ideas presented here, including this one. But, since the main proposal (async=false) is already being implemented by at least two major browsers, I'm not sure if the tide will be changed or not.

</blockquote>

<blockquote style="background-color:#ddd;">
Also, the suggestion of handling the "preload" and deferred execution via the script tag's `readyState` property is very similar in spirit to the suggestion that was made to explicitly support [[Dynamic_Script_Execution_Order#Explicit_support_for_.22text.2Fcache.22_MIME_type_behavior|preloading into cache without execution]]. As I said, either of those two approaches might work, but they both put more of the onus of complexity in managing multiple dependencies on the high-level code (author, script loader, etc). I'm more in favor of this functionality being explicitly built-in natively into the queues. As always, I welcome comments to any side of this discussion.

[[User:Getify|Getify]] 18:35, 15 December 2010 (UTC)
</blockquote>

b) in Gecko and Opera, the default behavior for script-inserted script elements is for them all to load in parallel, but execute serially in insertion order. Technically, this makes it impossible to dynamically load independent script elements and have them execute in "as fast as possible" mode.

As described above, both behaviors are desirable under different circumstances, but each of the two camps provides only one behavior, and no way to straightforwardly achieve the other. This obviously creates a big nightmare interoperability-wise when trying to provide a general script loader cross-browser.

Since it is observed that the behavior in (a) is more detrimental (race-condition wise) for the case where dependencies exist, script loaders like LABjs had to find some way around this problem while still attempting the best possible parallel loading performance. However, the trick used is hacky and not completely reliable -- yet it is the best way to solve the use-case in <s>IE and </s>Webkit.

For Gecko/Opera, the concession was just (silently) made that the lesser-common use case of "as fast as possible" wasn't possible, but degraded fine to "insertion order execution", while keeping the parallel loading benefits.

<blockquote style="background-color: #EEEEEE">
Gecko's strict execution order creates dependencies between scripts which are unrelated and prevents the ability mitigate the impact of server outages / network latency. This is exacerbated by the fact that Gecko, unlike IE and WebKit, provides no mechanism to <b>remove</b> scripts from the execution queue.

Consider the case where JSONP is used to provide auto-completion. The user types "hello" and the JSONP request is made; however, the "currently" loading script is out-of-date as soon as the user modifies his search to "hello world". Gecko's algorithm requires the out-of-date request load and execute before the second request.
</blockquote>

Recently, Gecko landed a [http://hg.mozilla.org/mozilla-central/rev/a60414d076b5 patch] to the trunk that stopped Gecko's existing behavior of preserving execution order, making script-inserted script elements now execute in "as fast as possible" mode similiar to IE/Webkit. Unfortunately, the "workaround" used in IE/Webkit (described in the next section) for dealing with parallel loading and execution-order dependencies does not work in Gecko, which means presently the use-case in question is now broken in Gecko trunk/FF4 nightlies.

Moreover, Webkit recently landed a [http://trac.webkit.org/changeset/67245 patch] to the trunk that stopped Webkit's non-standard but long-held behavior (also used in the "workaround" described in the next section) of loading into cache script resources with an unrecognized "type" value, but silently not executing them. This behvaior (while hacky) is central to being able to address the use-case in question in Webkit, so at present, Webkit nightlies are now also entirely broken on the use-case (though in a different way than Gecko).

Both the Gecko change and the Webkit change are well-intentioned, as they are bringing the respective browser more in line with the HTML spec. However, what's really been demonstrated is that the HTML spec is not properly handling this use-case, and so the goal is not to address the browser issues raised with more awkward hacks, but to address the shortcomings of the spec first, and then encourage all browsers to adhere to such.

<blockquote style="background-color: #EEEEEE">
Considering Internet Explorer's readyState implementation provides a means of both parallel loading and preserving execution order can be achieved, perhaps its "readyState" property and onreadystatechange event should be included.
</blockquote>

=== Current Usage and Workarounds ===
To work around the limitation in IE/Webkit(prior to the above noted patch) of not being able to rely on script order execution for parallel loaded scripts, a "preloading" trick was developed. This trick relied on non-standard (but long-held) behavior in these browsers that a script-inserted script element with an unrecognized "type" value (such as "script/cache") would be fetched/loaded, but would not execute. This had the effect of loading the resource into cache, and then firing the "load" handlers to let the page know when the resource was completely in cache.

Assuming that the resource was served with proper caching headers, and was in fact in the cache, it could then be executed (nearly) immediately when it was the proper execution order time by re-requesting the same resource via another script-inserted script element with the proper "text/javascript" type value, pulling the resource from the cache and executing it, without another server round-trip.

Of course, the assumption of proper cache headers is a huge one, and not at all reliable. Some recent estimates by performance optimization specialists have suggested as much as 70% of scripts across the internet are not served with proper caching headers, which means that such scripts would be completely ineffective if loaded using this (or a similar) technique. The script resource would end up being loaded completely a second-time, and the "near immediate" execution would obviously be false, and thus race conditions would ensue.

It's important to note at this point that the new <link rel=prefetch> facility has been suggested as a better workaround, but it suffers the same ill-fated assumption of script cacheability. Still others have suggested "new Image().src=..." or the [http://www.phpied.com/preload-then-execute/ <object> preloading trick] suggested by Stoyan Stefanov. Again, these tricks unwisely assume cacheability, for the "preloading" trick to solve the use-case in question.

=== At Risk ===
Currently, there are several large/popular web sites which are either currently (or who intend to soon) use LABjs in such a way as to run afoul of the new Gecko and Webkit behavioral changes with LABjs failing to operate properly. It's important to note that the problems of race conditions can be subtle and hard to detect, and so merely loading up such sites and failing to observe overt failure is not sufficient.

Sites which are known to have LABjs loading techniques in place with currently broken (or susceptible to such breakage in the near future) behavior are:

* [http://twitter.com Twitter]
* [http://zappos.com Zappos]
* [http://vimeo.com Vimeo]
* [http://mefeedia.com MeFeedia]
* [http://blog.getify.com Getify Solutions blog (my blog)]
* [http://flensed.com flensed Flash+JavaScript browser shims (cross-domain Ajax, cross-browser cookies, etc)]

Rather than getting hung up in the syntax of usage in LABjs that is or is not going to break, it's best to just think of the problem this way:

Does a site need to load more than one script, at least one of which comes from a remote domain location (like a CDN), and for which among the scripts there's at least one execution-order dependency among them? If so, then that site is susceptible to the current/future breakage if the HTML spec (and browsers) do not address this use case.

A common example (in use on many sites) of such might be loading:

* jQuery from the CDN
* jQuery-UI from the CDN
* plugins and usage code in one or more local files
* Google Analytics from the Google domain

Note that the emergence of popular script frameworks and their hosting on public CDN's is leading to more and more sites loading scripts from both local and remote locations, and also to loading more files that have dependencies (rather than the practice of concat'ing all files into one file to avoid dependency issues).

Any site which fits a profile like the above, and which might currently (many do), or in the future want to, use a script loader to improve their loading performance, will fail to achieve what they want cross-browser and in a performant way, if the HTML spec (and browsers) do not address the use case.

=== Benefits ===
The benefits of addressing both behaviors directly (without "preloading" tricks and bad assumption reliance) have been implied in the above discussion, but in short are:

a) clear and simplified code for script loaders, which leads to easier use by authors of more pages, which in turn leads to better web performance (as demonstrated clearly by intelligent script loading techniques as compared to just simple <script> tags in HTML markup)

b) full access to either/both of the execution-order behaviors (as the author sees fit), regardless of browser

c) avoiding reliance on bad assumptions (like cacheability) as a sufficient way to address the use-case

=== External Discussions of this Feature ===

* <cite>[http://lists.w3.org/Archives/Public/public-html/2010Oct/0088.html W3C public-html email thread]</cite>

* <cite>[http://www.w3.org/Bugs/Public/show_bug.cgi?id=11295 W3C Bug #11295]</cite>

* <cite>[https://bugzilla.mozilla.org/show_bug.cgi?id=602838 Mozilla Bug #602838]</cite>

* <cite>[https://bugs.webkit.org/show_bug.cgi?id=50115 Webkit Bug #50115]</cite>

* <cite>[http://hsivonen.iki.fi/script-execution/ HTML5 Script Execution Changes in Firefox 4 Beta 7]</cite>

* <cite>[http://blog.getify.com/2010/10/labjs-w3c-brief-update/ LABjs and W3C... brief update]</cite>

* <cite>[http://blog.getify.com/2010/10/ff4-script-loaders-and-order-preservation/ FF4, script loaders, and order preservation]</cite>

== Proposed Solutions ==

=== My Solution ===
The current proposal most well supported from the email discussion thread, and the one which I feel makes most sense, is described here.

The HTML spec already defines the "async" attribute for parser-inserted script tags, which when set to "true", changes their execution order behavior to be like script-inserted script-elements (in IE/Webkit), which is that they load in parallel and execute "as fast as possible" (ostensibly because the author is expressing no dependencies between multiple such "async"-marked scripts). Parser-inserted script elements without "async" (or with it set to false) behave as before and expected, which is that they load in parallel but execute in order.

However, the HTML spec does not define the "async" property (or any such behavior) for script-inserted script nodes (such as those created by a script loader). Instead, the spec implies that "async=true" like behavior is always true for such script-inserted script elements.

What is proposed is:

a) Script-inserted script elements should have (and respect the value of) an "async" property which is basically identical to the "async" attribute for parser-inserted script elements. That is, script elements with the "async" property set to "true" will behave accordingly, as will script elements with the "async" property set to false.

Essentially, the proposal is to mirror the "async" attribute behavior of parser-inserted script elements as an "async" property on script-inserted script elements. This has the benefit of using an existing facility and extending it (from current spec) in a way that is sensisble and symmetric with its current definition.
<blockquote style="background-color: #EFEFEF">
The scriptgroup or `readyState` alternate proposals allow for dependency management to be done in high-level code. The singular syncrhonized execution queue proposed here introduces artificial dependencies, undermining some of the benefits dynamic script loading provides.
</blockquote>

<blockquote style="background-color: #ccc;">
It's important to note that `async=false` scripts will load in a separate queue from `async=true` scripts. It's not that all scripts will now be forced into this insertion-order-execution queue. An author (or script loader) can chose which queue to put a script loading into based on the needs of the page and the resource. If I have a few scripts that are unrelated to each other and the main page (like Google Analytics, social sharing buttons, etc), I'll load those via `async=true`. For other scripts, where order matters for dependency sake, I'll use `async=false`. I think having both those queues available to high-level code is enough control over loading to serve the majority of use-cases pretty well.
<blockquote style="background-color: #EFEFEF">
If at any point these services begin dynamically loading `async=false` scripts of their own, they will begin blocking. This can lead to unexpected behavior of existing code as third-party libraries and services change. It would seem the specification should provide a means by which this blocking can be isolated to dependencies defined by the author and ordered execution not introduce conditions that allow unrelated libraries to affect this.
</blockquote>
</blockquote>

b) Furthermore, to aid in "feature-detection" of such new behavior, the proposal is to have the default value for the "async" property of script-inserted script elements be "true" (and of course the associated behavior thereof).

There are two major benefits to (b). One is that it provides a way to feature test such new behavior by not just looking for the existence of the "async" property on script elements, but specifically that the default value is "true" (which is opposite of what it would currently/normally be). Secondly, defaulting to "async=true" behavior for script-inserted script elements would preserve the default behavior of IE and Webkit, meaning there'd be less of a chance of breaking existing web content in either of those two browsers.

It's also important to note that there is no implied or requested effect or dependency between script-inserted script elements and parser-inserted script elements -- the two types of scripts would load and execute in entirely separate behavioral sandboxes.

==== Proposal Amendment: Events ====
In addition to standardizing how scripts load and execute, it's also important to standardize the load and error events, and under what circumstances they fire, etc. Without reliable load/error events, the main proposal is not reliable and is thus unhelpful for the use-case.

A script-inserted script element must fire the "load" event only once, when:

a) immediately after the resource finishes loading, but before parsing/execution, AND

b) the script element loads any non-empty content (that is, it was a successful HTTP request), AND

c) the script element has either loaded from the remote location, or is loaded from the brower cache

Specifically, the script "load" event must come immediately between the script element finishing loading and the script element being parsed/executed. If the script resource successfully loads, nothing should interrupt the sequence of fininshing loading, the "load" event firing, and the script being parsed/executed.

A script-inserted script element must fire the "error" event only once, when:

a) immediately after a loading failure for the resource is detected (that is, an HTTP error received, such as 404, 500, 503, etc).

Either the "load" or "error" event, but not both, will fire, and only once, for every script-inserted script element.

NOTE: "load" and "error" events on script-inserted script elements must fire synchronously to ensure event reliability.

A case may be made for adding the "load" and "error" events as described here to parser-inserted script elements as well.

==== Processing Model ====
Script inserted script elements will have an "async" property that defaults to "true". If the author does not change the value, all such requested script loadings will be in their own "queue" and will default to "as fast as possible" execution behavior. For any script elements that the author sets "async=false", those scripts will load in a separate "queue", and will execute in insertion order only. Again, these two "queues" will operate strictly independent of each other.

==== Processing Model Details (without the event amendment) ====

When a script element node is created, if it is being flagged as parser-inserted, set its force-async flag to false. Otherwise, set its force-async flag to true. (Note that createContextualFragment, innerHTML and XSLTProcessor::transformToFragment-created scripts are not flagged as parser-inserted.) This flag setting happens before any attributes (even parser-set ones) are set on the node.

When a previously-created script element node loses its parser-insertedness, if the element doesn't have the async content attribute, set the force-async flag to true and false otherwise.

When a script element node obtains the async content attribute (via setAttribute, setAttributeNode, setAttributeNS, by the fragment parser or the XSLTProcessor adding the attribute, etc.), set the force-async flag to false. (Note that calling removeAttribute("async") doesn't modify the force-async flag.)

The async IDL attribute must behave as follows:
* Upon setting, set the force-async flag to false and then reflect the async content attribute.
* Upon getting, if the force-async flag is true, return true. Otherwise, reflect the async content attribute.

In step 13. of http://www.whatwg.org/specs/web-apps/current-work/#running-a-script before the case "If the element has a src attribute" add a case:
If the script has a src attribute and the async IDL property getter returns false,
The element must be added to the queue of ordered script-inserted external scripts of the Document of the script element at the time the running a script algorithm started.

The task that the networking task source places on the task queue once the fetching algorithm has completed must run these steps:
# If the queue of ordered script-inserted external scripts is empty or the first script in the queue of ordered script-inserted external scripts has not been fetched yet, abort these steps.
# Execute the first script in the queue of ordered script-inserted external scripts.
# Remove the first script from queue of ordered script-inserted external scripts.
# Goto step #1.

Modify step 5 of http://www.whatwg.org/specs/web-apps/current-work/#the-end to say:
Spin the event loop until the set of scripts that will execute as soon as possible is empty and the queue of ordered script-inserted external scripts is empty.

==== Limitations ====
The two behaviors being identified solve either the case where no dependencies exist, or where a linear dependency chain exists (and which the script elements can be requested to execute in that order). It is possible that some authors have a more complex non-linear dependency chain that they would like to express. This would obviously require a much more complex API and spec change, and since that use-case has not (yet) surfaced as a particularly main-stream request, I believe it would be overengineering to try to address it with this proposed change set.

In addition, it's been duly noted that it's undesirable (and potentially confusing/problematic) to intentionally build in the inconsistency of having the "async" attribute (for parser-inserted scripts) and the "async" property (for script-inserted scripts) have different default values ("false" for the attribute, "true" for the property).

It's also been a point of discussion whether or not such a spec change has enough "carrot" to entice the browser vendors (namely IE and Webkit) to implement the behavior. Moreover, there's been some concern that if the default value for the "async" property were made to be "false" (like the attribute) to be more consistent and conservative, then it would possibly give the perception to IE and Webkit of "losing" some performance to cut out their default "as fast as possible" behavior.

=== Alternate Proposals ===
One early proposal on the email list was to introduce an entirely new property like "ordered" which an author could add to a script-inserted script element to instruct the browser to put it into the queue of execution-order-preserving script loadings. While such a property would address the use case, it introduces another property and thus more complicates the issue. It also fails to address the current spec inconsistency (which is confusing to new comers) that "async" is not a present/respected property in mirror of the attribute of the same name.

Another suggestion was a "waitFor" property that would be added to script elements and would specify a list of one or more DOM id's of other script elements that the current script should "wait for" in terms of execution. Again, this would solve the use case, but in a more complicated way, and there are concerns that it would be too confusing for the normal use-case.

Several suggestions have come in the form of creating explicit "preloading" (similar to <link rel=prefetch>), but as described above, "preloading" to solve this use case is a non-ideal hack and highly susceptible to breakage if the script fails to be sent with proper caching headers.

It's also been suggested that since this type of behavior is somewhat complicated, it may be better to intentionally obfuscate or complicate any such facility in the HTML, so as to make the barrier-to-entry rather high and force users to know what they are doing before doing it.

It's been suggested that "defer" already preserves execution order. However, "defer" is only defined for parser-inserted scripts, and thus is not applicable to the use-case in question from an on-demand point of view. Also, "defer" scripts explicitly way for DOMContentLoaded, even if they're ready to execute sooner. So this is less than desired.

Yet another proposal is a "document.executeScripts()" API, where an author can specify multiple sets of scripts that can load in parallel and it will enforce their execution order. A variation on that same idea was to use the "importScripts" from the Web Workers spec, however "importScripts" is synchronous (undesirable performance wise, obviously). The main downside (besides extra API complication) to "document.executeScripts()" is that there seem to be quite a few script execution properties/behaviors (including "document.currentScript" and charset override) which would have to be duplicated into this API facility.

==== "Script Group" element ====
One recent alternate proposal bears some special consideration, as it seems like it might be a decent option (although certainly more of a radical change for the spec and for browsers to implement). But it has the appearance of being pretty straightforward and semantic for authors to use, perhaps even more so than using "async".

The proposal is to create a new HTML element, called perhaps <scriptGroup>, <collection>, etc. Specifically, this element must be able to be inserted wherever a <script> element can currently be inserted. The "script group" element is intended to signify that all script elements added to it must perserve insertion execution order. This element wouldn't have much (but still some, explained in a moment) meaning in a parser-inserted context, since parser-inserted scripts already preserve order among themselves.

An advantage of the "script group" element would be to give a direct and easy way to attach event listeners ("load" and "error") to the entire group, rather than having to internally track events for each element if all you care about is the final "load" event, for instance. In the case of event handling, the "script group" element would have perhaps some benefit even in parser-inserted (markup) context.

The element would need to have an "id" property, and possibly attributes for "load" and "error" events.

A variation on how to look at this proposal is that a "script group" element could have an attribute/property on it (perhaps called "ordered") which would allow the group to either be order preserved or not. This would make the "script group" element much more useful in the parser-inserted context, as it would sort of be a shortcut to setting "async=true" on all the child script elements.

The "script group" element might look like this:

<scriptGroup id="group1">
<script src="foo.js"></script>
<script src="bar.js"></script>
<script>
somethingInline();
</script>
</scriptGroup>

Or, with the "ordered" attribute to explicitly control ordering behavior for the group:

<scriptGroup id="group1" ordered="true">
<script src="foo.js"></script>
<script src="bar.js"></script>
<script>
somethingInline();
</script>
</scriptGroup>

<scriptGroup id="group2" ordered="false" onload="alldone();">
<script src="baz.js"></script>
<script src="far.js"></script>
<script src="zab.js"></script>
</scriptGroup>

While the "script group" element is definitely more complicated to define and implement, it does have some semantic advantages for authors, and it also would significantly reduce the internal complexity of script loaders like LABjs. It would give authors (either directly or through script loaders) the flexibility to group scripts together into one of the two aforementioned behaviors (execution "as fast as possible" or "in insertion order"), and to easily access both behaviors in the same page.

==== Explicit support for "text/cache" MIME type behavior ====
Yet another alternate proposal has been suggested in the [[Talk:Dynamic_Script_Execution_Order]] thread.

Essentially, the proposal is that <script> tags directly support being declared with a `type` value of "text/cache". The behavior would be that the script resource is fetched, as the load events fired, as normal, but that the script itself would not be executed. Then later, at the desired time, the script in that element could be executed by changing the `type` value from "text/cache" to "text/javascript".

The browser would probably need to keep track (via some internal flag) that the script node is only ever executed once. Also, it's an open question if such a "cached" script node should be able to have its script content modified before execution via the `text` property.

==== readyState "preloading" ====
Per the suggestion/comment added to the above [[Dynamic_Script_Execution_Order#Current_Limitations|Current Limitations]] section, it's been suggested that IE's current behavior with respect to the `readyState` property can adequately serve the use-case in question. This alternate proposal is very similar in spirit to the [[Dynamic_Script_Execution_Order#Explicit_support_for_.22text.2Fcache.22_MIME_type_behavior|previous section on explicit support for "text/cache"]] mime-type value.

The idea is that IE will begin fetching into the cache a script resource as soon as the `src` attribute of the dynamic script element is set. But IE will not execute the script (even if it finishes loading) until the script element is added to the DOM. However, the `readyState` property of the element, combined with the `onreadystatechange` handler listening for changes, can detect when the script has finished loading, by receiving the "loaded" value.

In this way, a script loader could "preload" a set of scripts all in parallel, but control their execution order by delaying the appending of the element to the DOM until execution is desired.

[[Category:Feature Request|Dynamic Script Execution Order]]

Dynamic Script Execution Order

2010-12-15T18:21:52Z

Serverherder: /* Current Limitations */

This page is intended to formalize the discussion around an important but currently underserved use-case (in both spec and various browser implementations): the need for a dynamic script loading facility that can download resources in parallel but ensure that they execute serially in insertion order, for dependency reasons.

A long email thread on the W3C public-html list, which began [http://lists.w3.org/Archives/Public/public-html/2010Oct/0088.html here] and for which a recent message is [http://lists.w3.org/Archives/Public/public-html/2010Oct/0415.html here], has been discussing this problem, but the email thread is becoming unruly and hard to track, so this wiki page will now be the official location to discuss the topic.

Briefly, this issue has arisen because recent "nightlies" changes in both Mozilla Gecko and Webkit have broken the ability for script-loaders like [http://labjs.com LABjs] to be able to download scripts in parallel but ensure their execution order. As a result of the discussion, it's become apparent that both the spec for, and various current browser implementations around, dynamic script loading is incomplete in addressing this use case, and that some change needs to occur.

There is one main proposal that has surfaced from the discussions, with several other alternatives having been discussed. This page will try to distill the long email thread down and clearly present the main proposal, objections, and alternative suggestions.

Please feel free to join the discussion of this topic in the [[Talk:Dynamic_Script_Execution_Order]] area.

== Use Case Description ==
Script tags/elements can either:

a) appear in the HTML markup ("parser-inserted"), OR

b) be dynamically appended to the DOM using document.createElement() ("script-inserted")

Parser-inserted script tags, up until recent browser versions, had the undesirable performance behavior of loading and executing serially, blocking everything else while doing so. Recently, many browsers have improved the situation by loading the scripts in parallel, but still executing them in order.

On-demand (or dynamic) script loading has emerged in recent years for a variety of different reasons, most notably the performance improvements to address such concerns. It is desired by many different scenarios to be able to download scripts to a page completely independently of the loading of the rest of a page's resources, or even well after a page has finished loading ("on-demand").

Recent additions to HTML spec such as "defer" and "async" were intended to address the use-case for parser-inserted script elements, but their behaviors have been unhelpful for the on-demand loading use-case (script-inserted script elements).

Thus, script loaders (like [http://labjs.com LABjs]) were developed to give page authors an easy way to specify one or more scripts to load (regardless of when in the life-time of the page that loading is requested), and for as many of them as possible to load in parallel, and for those scripts to be loadable from any local or remote domain location, and for the script loader to be able to control the execution order (if the usage of the script loader's API expresses the need to) to preserve dependencies between the scripts.

Sometimes, dynamic script loading is used to load totally independent scripts, and thus "as fast as possible" execution is desired. Other times (and possibly more frequently), multiple scripts are loaded with some dependencies among them, requiring them to execute in a certain order.

What is needed is some facility by which a script loader can express that dynamic script loading either does or does not need execution order preserved among the queue of requested script loadings.

=== Current Limitations ===
Unfortunately, browser behavior around script-inserted script elements and their loading and execution behavior is splintered. There are, at present, two main camps of behavior:

a) in IE and Webkit (including Chrome), the default behavior for script-inserted script elements is for them all to execute in "as fast as possible" mode, meaning there's no guarantee about ordering. This effectively makes on-demand (dynamic) script loading impossible to work in parallel-mode if the resources in question have dependencies -- the only straight-forward way to handle things is to load each file and execute, serially, losing the parallel loading performance benefits.
<blockquote style="background-color: #EEEEEE">
I'm not sure if this is the case.

IE will start fetching resources without execution simply by setting the src attribute. Scripts will not execute, however, until they are added to the document. Since IE supports the readyState attribute and readystatechange event, it's possible to load scripts in parallel and execute them in order without resorting to invalid type attribute hack-ery.

<pre style="background-color:white" lang="javascript">
script= document.createElement("SCRIPT");
script.onreadystatechange= function(){
if(this.readyState == 'loaded')
/*
Network fetch is now complete, following
triggers synchronous execution.
*/
document.body.appendChild(this);
else if(this.readyState == "complete")
this.onreadystatechange= null;
}
script.src= "foo.js";
/* Network fetching begins now */
</pre>
</blockquote>

<blockquote style="background-color: #ccc">
I've experimented with such things heavily in the past, and I'm fairly suspicious that this is not reliable across various versions of IE (6-9), nor does it work reliably the same depending on if an element is already in the browser cache or not. I'm not 100% certain that what you suggest is flawed, but I have a strong hunch that it can be shown to have some holes in it for IE loading. I will try to create some test cases to prove or disprove.
<blockquote style="background-color: #EEEEEE">
When loading a script that is in the cache, IE requires the event handler be installed prior to setting the `src` attribute. Otherwise the element's transition to the "loaded" state will be missed. IE routinely "skips" ready state transitions when cached scripts are immediately inserted into the DOM so suspicion is understandable; however, delayed insertion works around this "problem". The script above has been tested in IE6-8 with scripts in a variety of caching states and found to work correctly.
</blockquote>

Moreover, you're suggesting something that is AFAIK only IE right now, and definitely appears to not be standardized. In the same way that I'm hesitant to continue pinning loading behavior on hacks like the invalid type attribute value, I wouldn't want to approach loading with this technique (even if it were proven reliable on all IE's under all caching circumstances) unless it was a serious proposal to the W3C to have this technique be the new standard (as opposed to the current proposal, as implemented by Mozilla and Webkit now).
<blockquote style="background-color: #EEEEEE">
I think you're right: Only IE impelements this event and property on script elements. The readystatechange event, however, is widely understood due to the XmlHttpRequest implementation and `readyState` property has been added to the `document` in WebKit, Mozilla and IE.
</blockquote>

That having been said, I think this is at least a viable candidate for "Alternate Proposals" and deserves to be listed as such. As always, I welcome input from the community on all the ideas presented here, including this one. But, since the main proposal (async=false) is already being implemented by at least two major browsers, I'm not sure if the tide will be changed or not.

</blockquote>

b) in Gecko and Opera, the default behavior for script-inserted script elements is for them all to load in parallel, but execute serially in insertion order. Technically, this makes it impossible to dynamically load independent script elements and have them execute in "as fast as possible" mode.

As described above, both behaviors are desirable under different circumstances, but each of the two camps provides only one behavior, and no way to straightforwardly achieve the other. This obviously creates a big nightmare interoperability-wise when trying to provide a general script loader cross-browser.

Since it is observed that the behavior in (a) is more detrimental (race-condition wise) for the case where dependencies exist, script loaders like LABjs had to find some way around this problem while still attempting the best possible parallel loading performance. However, the trick used is hacky and not completely reliable -- yet it is the best way to solve the use-case in <s>IE and </s>Webkit.

For Gecko/Opera, the concession was just (silently) made that the lesser-common use case of "as fast as possible" wasn't possible, but degraded fine to "insertion order execution", while keeping the parallel loading benefits.

<blockquote style="background-color: #EEEEEE">
Gecko's strict execution order creates dependencies between scripts which are unrelated and prevents the ability mitigate the impact of server outages / network latency. This is exacerbated by the fact that Gecko, unlike IE and WebKit, provides no mechanism to <b>remove</b> scripts from the execution queue.

Consider the case where JSONP is used to provide auto-completion. The user types "hello" and the JSONP request is made; however, the "currently" loading script is out-of-date as soon as the user modifies his search to "hello world". Gecko's algorithm requires the out-of-date request load and execute before the second request.
</blockquote>

Recently, Gecko landed a [http://hg.mozilla.org/mozilla-central/rev/a60414d076b5 patch] to the trunk that stopped Gecko's existing behavior of preserving execution order, making script-inserted script elements now execute in "as fast as possible" mode similiar to IE/Webkit. Unfortunately, the "workaround" used in IE/Webkit (described in the next section) for dealing with parallel loading and execution-order dependencies does not work in Gecko, which means presently the use-case in question is now broken in Gecko trunk/FF4 nightlies.

Moreover, Webkit recently landed a [http://trac.webkit.org/changeset/67245 patch] to the trunk that stopped Webkit's non-standard but long-held behavior (also used in the "workaround" described in the next section) of loading into cache script resources with an unrecognized "type" value, but silently not executing them. This behvaior (while hacky) is central to being able to address the use-case in question in Webkit, so at present, Webkit nightlies are now also entirely broken on the use-case (though in a different way than Gecko).

Both the Gecko change and the Webkit change are well-intentioned, as they are bringing the respective browser more in line with the HTML spec. However, what's really been demonstrated is that the HTML spec is not properly handling this use-case, and so the goal is not to address the browser issues raised with more awkward hacks, but to address the shortcomings of the spec first, and then encourage all browsers to adhere to such.

<blockquote style="background-color: #EEEEEE">
Considering Internet Explorer's readyState implementation provides a means of both parallel loading and preserving execution order can be achieved, perhaps its "readyState" property and onreadystatechange event should be included.
</blockquote>

=== Current Usage and Workarounds ===
To work around the limitation in IE/Webkit(prior to the above noted patch) of not being able to rely on script order execution for parallel loaded scripts, a "preloading" trick was developed. This trick relied on non-standard (but long-held) behavior in these browsers that a script-inserted script element with an unrecognized "type" value (such as "script/cache") would be fetched/loaded, but would not execute. This had the effect of loading the resource into cache, and then firing the "load" handlers to let the page know when the resource was completely in cache.

Assuming that the resource was served with proper caching headers, and was in fact in the cache, it could then be executed (nearly) immediately when it was the proper execution order time by re-requesting the same resource via another script-inserted script element with the proper "text/javascript" type value, pulling the resource from the cache and executing it, without another server round-trip.

Of course, the assumption of proper cache headers is a huge one, and not at all reliable. Some recent estimates by performance optimization specialists have suggested as much as 70% of scripts across the internet are not served with proper caching headers, which means that such scripts would be completely ineffective if loaded using this (or a similar) technique. The script resource would end up being loaded completely a second-time, and the "near immediate" execution would obviously be false, and thus race conditions would ensue.

It's important to note at this point that the new <link rel=prefetch> facility has been suggested as a better workaround, but it suffers the same ill-fated assumption of script cacheability. Still others have suggested "new Image().src=..." or the [http://www.phpied.com/preload-then-execute/ <object> preloading trick] suggested by Stoyan Stefanov. Again, these tricks unwisely assume cacheability, for the "preloading" trick to solve the use-case in question.

=== At Risk ===
Currently, there are several large/popular web sites which are either currently (or who intend to soon) use LABjs in such a way as to run afoul of the new Gecko and Webkit behavioral changes with LABjs failing to operate properly. It's important to note that the problems of race conditions can be subtle and hard to detect, and so merely loading up such sites and failing to observe overt failure is not sufficient.

Sites which are known to have LABjs loading techniques in place with currently broken (or susceptible to such breakage in the near future) behavior are:

* [http://twitter.com Twitter]
* [http://zappos.com Zappos]
* [http://vimeo.com Vimeo]
* [http://mefeedia.com MeFeedia]
* [http://blog.getify.com Getify Solutions blog (my blog)]
* [http://flensed.com flensed Flash+JavaScript browser shims (cross-domain Ajax, cross-browser cookies, etc)]

Rather than getting hung up in the syntax of usage in LABjs that is or is not going to break, it's best to just think of the problem this way:

Does a site need to load more than one script, at least one of which comes from a remote domain location (like a CDN), and for which among the scripts there's at least one execution-order dependency among them? If so, then that site is susceptible to the current/future breakage if the HTML spec (and browsers) do not address this use case.

A common example (in use on many sites) of such might be loading:

* jQuery from the CDN
* jQuery-UI from the CDN
* plugins and usage code in one or more local files
* Google Analytics from the Google domain

Note that the emergence of popular script frameworks and their hosting on public CDN's is leading to more and more sites loading scripts from both local and remote locations, and also to loading more files that have dependencies (rather than the practice of concat'ing all files into one file to avoid dependency issues).

Any site which fits a profile like the above, and which might currently (many do), or in the future want to, use a script loader to improve their loading performance, will fail to achieve what they want cross-browser and in a performant way, if the HTML spec (and browsers) do not address the use case.

=== Benefits ===
The benefits of addressing both behaviors directly (without "preloading" tricks and bad assumption reliance) have been implied in the above discussion, but in short are:

a) clear and simplified code for script loaders, which leads to easier use by authors of more pages, which in turn leads to better web performance (as demonstrated clearly by intelligent script loading techniques as compared to just simple <script> tags in HTML markup)

b) full access to either/both of the execution-order behaviors (as the author sees fit), regardless of browser

c) avoiding reliance on bad assumptions (like cacheability) as a sufficient way to address the use-case

=== External Discussions of this Feature ===

* <cite>[http://lists.w3.org/Archives/Public/public-html/2010Oct/0088.html W3C public-html email thread]</cite>

* <cite>[http://www.w3.org/Bugs/Public/show_bug.cgi?id=11295 W3C Bug #11295]</cite>

* <cite>[https://bugzilla.mozilla.org/show_bug.cgi?id=602838 Mozilla Bug #602838]</cite>

* <cite>[https://bugs.webkit.org/show_bug.cgi?id=50115 Webkit Bug #50115]</cite>

* <cite>[http://hsivonen.iki.fi/script-execution/ HTML5 Script Execution Changes in Firefox 4 Beta 7]</cite>

* <cite>[http://blog.getify.com/2010/10/labjs-w3c-brief-update/ LABjs and W3C... brief update]</cite>

* <cite>[http://blog.getify.com/2010/10/ff4-script-loaders-and-order-preservation/ FF4, script loaders, and order preservation]</cite>

== Proposed Solutions ==

=== My Solution ===
The current proposal most well supported from the email discussion thread, and the one which I feel makes most sense, is described here.

The HTML spec already defines the "async" attribute for parser-inserted script tags, which when set to "true", changes their execution order behavior to be like script-inserted script-elements (in IE/Webkit), which is that they load in parallel and execute "as fast as possible" (ostensibly because the author is expressing no dependencies between multiple such "async"-marked scripts). Parser-inserted script elements without "async" (or with it set to false) behave as before and expected, which is that they load in parallel but execute in order.

However, the HTML spec does not define the "async" property (or any such behavior) for script-inserted script nodes (such as those created by a script loader). Instead, the spec implies that "async=true" like behavior is always true for such script-inserted script elements.

What is proposed is:

a) Script-inserted script elements should have (and respect the value of) an "async" property which is basically identical to the "async" attribute for parser-inserted script elements. That is, script elements with the "async" property set to "true" will behave accordingly, as will script elements with the "async" property set to false.

Essentially, the proposal is to mirror the "async" attribute behavior of parser-inserted script elements as an "async" property on script-inserted script elements. This has the benefit of using an existing facility and extending it (from current spec) in a way that is sensisble and symmetric with its current definition.
<blockquote style="background-color: #EFEFEF">
The scriptgroup or `readyState` alternate proposals allow for dependency management to be done in high-level code. The singular syncrhonized execution queue proposed here introduces artificial dependencies, undermining some of the benefits dynamic script loading provides.
</blockquote>

<blockquote style="background-color: #ccc;">
It's important to note that `async=false` scripts will load in a separate queue from `async=true` scripts. It's not that all scripts will now be forced into this insertion-order-execution queue. An author (or script loader) can chose which queue to put a script loading into based on the needs of the page and the resource. If I have a few scripts that are unrelated to each other and the main page (like Google Analytics, social sharing buttons, etc), I'll load those via `async=true`. For other scripts, where order matters for dependency sake, I'll use `async=false`. I think having both those queues available to high-level code is enough control over loading to serve the majority of use-cases pretty well.
</blockquote>

b) Furthermore, to aid in "feature-detection" of such new behavior, the proposal is to have the default value for the "async" property of script-inserted script elements be "true" (and of course the associated behavior thereof).

There are two major benefits to (b). One is that it provides a way to feature test such new behavior by not just looking for the existence of the "async" property on script elements, but specifically that the default value is "true" (which is opposite of what it would currently/normally be). Secondly, defaulting to "async=true" behavior for script-inserted script elements would preserve the default behavior of IE and Webkit, meaning there'd be less of a chance of breaking existing web content in either of those two browsers.

It's also important to note that there is no implied or requested effect or dependency between script-inserted script elements and parser-inserted script elements -- the two types of scripts would load and execute in entirely separate behavioral sandboxes.

==== Proposal Amendment: Events ====
In addition to standardizing how scripts load and execute, it's also important to standardize the load and error events, and under what circumstances they fire, etc. Without reliable load/error events, the main proposal is not reliable and is thus unhelpful for the use-case.

A script-inserted script element must fire the "load" event only once, when:

a) immediately after the resource finishes loading, but before parsing/execution, AND

b) the script element loads any non-empty content (that is, it was a successful HTTP request), AND

c) the script element has either loaded from the remote location, or is loaded from the brower cache

Specifically, the script "load" event must come immediately between the script element finishing loading and the script element being parsed/executed. If the script resource successfully loads, nothing should interrupt the sequence of fininshing loading, the "load" event firing, and the script being parsed/executed.

A script-inserted script element must fire the "error" event only once, when:

a) immediately after a loading failure for the resource is detected (that is, an HTTP error received, such as 404, 500, 503, etc).

Either the "load" or "error" event, but not both, will fire, and only once, for every script-inserted script element.

NOTE: "load" and "error" events on script-inserted script elements must fire synchronously to ensure event reliability.

A case may be made for adding the "load" and "error" events as described here to parser-inserted script elements as well.

==== Processing Model ====
Script inserted script elements will have an "async" property that defaults to "true". If the author does not change the value, all such requested script loadings will be in their own "queue" and will default to "as fast as possible" execution behavior. For any script elements that the author sets "async=false", those scripts will load in a separate "queue", and will execute in insertion order only. Again, these two "queues" will operate strictly independent of each other.

==== Processing Model Details (without the event amendment) ====

When a script element node is created, if it is being flagged as parser-inserted, set its force-async flag to false. Otherwise, set its force-async flag to true. (Note that createContextualFragment, innerHTML and XSLTProcessor::transformToFragment-created scripts are not flagged as parser-inserted.) This flag setting happens before any attributes (even parser-set ones) are set on the node.

When a previously-created script element node loses its parser-insertedness, if the element doesn't have the async content attribute, set the force-async flag to true and false otherwise.

When a script element node obtains the async content attribute (via setAttribute, setAttributeNode, setAttributeNS, by the fragment parser or the XSLTProcessor adding the attribute, etc.), set the force-async flag to false. (Note that calling removeAttribute("async") doesn't modify the force-async flag.)

The async IDL attribute must behave as follows:
* Upon setting, set the force-async flag to false and then reflect the async content attribute.
* Upon getting, if the force-async flag is true, return true. Otherwise, reflect the async content attribute.

In step 13. of http://www.whatwg.org/specs/web-apps/current-work/#running-a-script before the case "If the element has a src attribute" add a case:
If the script has a src attribute and the async IDL property getter returns false,
The element must be added to the queue of ordered script-inserted external scripts of the Document of the script element at the time the running a script algorithm started.

The task that the networking task source places on the task queue once the fetching algorithm has completed must run these steps:
# If the queue of ordered script-inserted external scripts is empty or the first script in the queue of ordered script-inserted external scripts has not been fetched yet, abort these steps.
# Execute the first script in the queue of ordered script-inserted external scripts.
# Remove the first script from queue of ordered script-inserted external scripts.
# Goto step #1.

Modify step 5 of http://www.whatwg.org/specs/web-apps/current-work/#the-end to say:
Spin the event loop until the set of scripts that will execute as soon as possible is empty and the queue of ordered script-inserted external scripts is empty.

==== Limitations ====
The two behaviors being identified solve either the case where no dependencies exist, or where a linear dependency chain exists (and which the script elements can be requested to execute in that order). It is possible that some authors have a more complex non-linear dependency chain that they would like to express. This would obviously require a much more complex API and spec change, and since that use-case has not (yet) surfaced as a particularly main-stream request, I believe it would be overengineering to try to address it with this proposed change set.

In addition, it's been duly noted that it's undesirable (and potentially confusing/problematic) to intentionally build in the inconsistency of having the "async" attribute (for parser-inserted scripts) and the "async" property (for script-inserted scripts) have different default values ("false" for the attribute, "true" for the property).

It's also been a point of discussion whether or not such a spec change has enough "carrot" to entice the browser vendors (namely IE and Webkit) to implement the behavior. Moreover, there's been some concern that if the default value for the "async" property were made to be "false" (like the attribute) to be more consistent and conservative, then it would possibly give the perception to IE and Webkit of "losing" some performance to cut out their default "as fast as possible" behavior.

=== Alternate Proposals ===
One early proposal on the email list was to introduce an entirely new property like "ordered" which an author could add to a script-inserted script element to instruct the browser to put it into the queue of execution-order-preserving script loadings. While such a property would address the use case, it introduces another property and thus more complicates the issue. It also fails to address the current spec inconsistency (which is confusing to new comers) that "async" is not a present/respected property in mirror of the attribute of the same name.

Another suggestion was a "waitFor" property that would be added to script elements and would specify a list of one or more DOM id's of other script elements that the current script should "wait for" in terms of execution. Again, this would solve the use case, but in a more complicated way, and there are concerns that it would be too confusing for the normal use-case.

Several suggestions have come in the form of creating explicit "preloading" (similar to <link rel=prefetch>), but as described above, "preloading" to solve this use case is a non-ideal hack and highly susceptible to breakage if the script fails to be sent with proper caching headers.

It's also been suggested that since this type of behavior is somewhat complicated, it may be better to intentionally obfuscate or complicate any such facility in the HTML, so as to make the barrier-to-entry rather high and force users to know what they are doing before doing it.

It's been suggested that "defer" already preserves execution order. However, "defer" is only defined for parser-inserted scripts, and thus is not applicable to the use-case in question from an on-demand point of view. Also, "defer" scripts explicitly way for DOMContentLoaded, even if they're ready to execute sooner. So this is less than desired.

Yet another proposal is a "document.executeScripts()" API, where an author can specify multiple sets of scripts that can load in parallel and it will enforce their execution order. A variation on that same idea was to use the "importScripts" from the Web Workers spec, however "importScripts" is synchronous (undesirable performance wise, obviously). The main downside (besides extra API complication) to "document.executeScripts()" is that there seem to be quite a few script execution properties/behaviors (including "document.currentScript" and charset override) which would have to be duplicated into this API facility.

==== "Script Group" element ====
One recent alternate proposal bears some special consideration, as it seems like it might be a decent option (although certainly more of a radical change for the spec and for browsers to implement). But it has the appearance of being pretty straightforward and semantic for authors to use, perhaps even more so than using "async".

The proposal is to create a new HTML element, called perhaps <scriptGroup>, <collection>, etc. Specifically, this element must be able to be inserted wherever a <script> element can currently be inserted. The "script group" element is intended to signify that all script elements added to it must perserve insertion execution order. This element wouldn't have much (but still some, explained in a moment) meaning in a parser-inserted context, since parser-inserted scripts already preserve order among themselves.

An advantage of the "script group" element would be to give a direct and easy way to attach event listeners ("load" and "error") to the entire group, rather than having to internally track events for each element if all you care about is the final "load" event, for instance. In the case of event handling, the "script group" element would have perhaps some benefit even in parser-inserted (markup) context.

The element would need to have an "id" property, and possibly attributes for "load" and "error" events.

A variation on how to look at this proposal is that a "script group" element could have an attribute/property on it (perhaps called "ordered") which would allow the group to either be order preserved or not. This would make the "script group" element much more useful in the parser-inserted context, as it would sort of be a shortcut to setting "async=true" on all the child script elements.

The "script group" element might look like this:

<scriptGroup id="group1">
<script src="foo.js"></script>
<script src="bar.js"></script>
<script>
somethingInline();
</script>
</scriptGroup>

Or, with the "ordered" attribute to explicitly control ordering behavior for the group:

<scriptGroup id="group1" ordered="true">
<script src="foo.js"></script>
<script src="bar.js"></script>
<script>
somethingInline();
</script>
</scriptGroup>

<scriptGroup id="group2" ordered="false" onload="alldone();">
<script src="baz.js"></script>
<script src="far.js"></script>
<script src="zab.js"></script>
</scriptGroup>

While the "script group" element is definitely more complicated to define and implement, it does have some semantic advantages for authors, and it also would significantly reduce the internal complexity of script loaders like LABjs. It would give authors (either directly or through script loaders) the flexibility to group scripts together into one of the two aforementioned behaviors (execution "as fast as possible" or "in insertion order"), and to easily access both behaviors in the same page.

==== Explicit support for "text/cache" MIME type behavior ====
Yet another alternate proposal has been suggested in the [[Talk:Dynamic_Script_Execution_Order]] thread.

Essentially, the proposal is that <script> tags directly support being declared with a `type` value of "text/cache". The behavior would be that the script resource is fetched, as the load events fired, as normal, but that the script itself would not be executed. Then later, at the desired time, the script in that element could be executed by changing the `type` value from "text/cache" to "text/javascript".

The browser would probably need to keep track (via some internal flag) that the script node is only ever executed once. Also, it's an open question if such a "cached" script node should be able to have its script content modified before execution via the `text` property.

==== readyState "preloading" ====
Per the suggestion/comment added to the above [[Dynamic_Script_Execution_Order#Current_Limitations|Current Limitations]] section, it's been suggested that IE's current behavior with respect to the `readyState` property can adequately serve the use-case in question.

The idea is that IE will begin fetching into the cache a script resource as soon as the `src` attribute of the dynamic script element is set. But IE will not execute the script (even if it finishes loading) until the script element is added to the DOM. However, the `readyState` property of the element, combined with the `onreadystatechange` handler listening for changes, can detect when the script has finished loading, by receiving the "loaded" value.

In this way, a script loader could "preload" a set of scripts all in parallel, but control their execution order by delaying the appending of the element to the DOM until execution is desired.

[[Category:Feature Request|Dynamic Script Execution Order]]

Dynamic Script Execution Order

2010-12-15T17:57:32Z

Serverherder: /* My Solution */

This page is intended to formalize the discussion around an important but currently underserved use-case (in both spec and various browser implementations): the need for a dynamic script loading facility that can download resources in parallel but ensure that they execute serially in insertion order, for dependency reasons.

A long email thread on the W3C public-html list, which began [http://lists.w3.org/Archives/Public/public-html/2010Oct/0088.html here] and for which a recent message is [http://lists.w3.org/Archives/Public/public-html/2010Oct/0415.html here], has been discussing this problem, but the email thread is becoming unruly and hard to track, so this wiki page will now be the official location to discuss the topic.

Briefly, this issue has arisen because recent "nightlies" changes in both Mozilla Gecko and Webkit have broken the ability for script-loaders like [http://labjs.com LABjs] to be able to download scripts in parallel but ensure their execution order. As a result of the discussion, it's become apparent that both the spec for, and various current browser implementations around, dynamic script loading is incomplete in addressing this use case, and that some change needs to occur.

There is one main proposal that has surfaced from the discussions, with several other alternatives having been discussed. This page will try to distill the long email thread down and clearly present the main proposal, objections, and alternative suggestions.

Please feel free to join the discussion of this topic in the [[Talk:Dynamic_Script_Execution_Order]] area.

== Use Case Description ==
Script tags/elements can either:

a) appear in the HTML markup ("parser-inserted"), OR

b) be dynamically appended to the DOM using document.createElement() ("script-inserted")

Parser-inserted script tags, up until recent browser versions, had the undesirable performance behavior of loading and executing serially, blocking everything else while doing so. Recently, many browsers have improved the situation by loading the scripts in parallel, but still executing them in order.

On-demand (or dynamic) script loading has emerged in recent years for a variety of different reasons, most notably the performance improvements to address such concerns. It is desired by many different scenarios to be able to download scripts to a page completely independently of the loading of the rest of a page's resources, or even well after a page has finished loading ("on-demand").

Recent additions to HTML spec such as "defer" and "async" were intended to address the use-case for parser-inserted script elements, but their behaviors have been unhelpful for the on-demand loading use-case (script-inserted script elements).

Thus, script loaders (like [http://labjs.com LABjs]) were developed to give page authors an easy way to specify one or more scripts to load (regardless of when in the life-time of the page that loading is requested), and for as many of them as possible to load in parallel, and for those scripts to be loadable from any local or remote domain location, and for the script loader to be able to control the execution order (if the usage of the script loader's API expresses the need to) to preserve dependencies between the scripts.

Sometimes, dynamic script loading is used to load totally independent scripts, and thus "as fast as possible" execution is desired. Other times (and possibly more frequently), multiple scripts are loaded with some dependencies among them, requiring them to execute in a certain order.

What is needed is some facility by which a script loader can express that dynamic script loading either does or does not need execution order preserved among the queue of requested script loadings.

=== Current Limitations ===
Unfortunately, browser behavior around script-inserted script elements and their loading and execution behavior is splintered. There are, at present, two main camps of behavior:

a) in IE and Webkit (including Chrome), the default behavior for script-inserted script elements is for them all to execute in "as fast as possible" mode, meaning there's no guarantee about ordering. This effectively makes on-demand (dynamic) script loading impossible to work in parallel-mode if the resources in question have dependencies -- the only straight-forward way to handle things is to load each file and execute, serially, losing the parallel loading performance benefits.
<blockquote style="background-color: #EEEEEE">
I'm not sure if this is the case.

IE will start fetching resources without execution simply by setting the src attribute. Scripts will not execute, however, until they are added to the document. Since IE supports the readyState attribute and readystatechange event, it's possible to load scripts in parallel and execute them in order without resorting to invalid type attribute hack-ery.

<pre style="background-color:white" lang="javascript">
script= document.createElement("SCRIPT");
script.onreadystatechange= function(){
if(this.readyState == 'loaded')
/*
Network fetch is now complete, following
triggers synchronous execution.
*/
document.body.appendChild(this);
else if(this.readyState == "complete")
this.onreadystatechange= null;
}
script.src= "foo.js";
/* Network fetching begins now */
</pre>
</blockquote>

<blockquote style="background-color: #ccc">
I've experimented with such things heavily in the past, and I'm fairly suspicious that this is not reliable across various versions of IE (6-9), nor does it work reliably the same depending on if an element is already in the browser cache or not. I'm not 100% certain that what you suggest is flawed, but I have a strong hunch that it can be shown to have some holes in it for IE loading. I will try to create some test cases to prove or disprove.

Moreover, you're suggesting something that is AFAIK only IE right now, and definitely appears to not be standardized. In the same way that I'm hesitant to continue pinning loading behavior on hacks like the invalid type attribute value, I wouldn't want to approach loading with this technique (even if it were proven reliable on all IE's under all caching circumstances) unless it was a serious proposal to the W3C to have this technique be the new standard (as opposed to the current proposal, as implemented by Mozilla and Webkit now).

That having been said, I think this is at least a viable candidate for "Alternate Proposals" and deserves to be listed as such. As always, I welcome input from the community on all the ideas presented here, including this one. But, since the main proposal (async=false) is already being implemented by at least two major browsers, I'm not sure if the tide will be changed or not.
</blockquote>

b) in Gecko and Opera, the default behavior for script-inserted script elements is for them all to load in parallel, but execute serially in insertion order. Technically, this makes it impossible to dynamically load independent script elements and have them execute in "as fast as possible" mode.

As described above, both behaviors are desirable under different circumstances, but each of the two camps provides only one behavior, and no way to straightforwardly achieve the other. This obviously creates a big nightmare interoperability-wise when trying to provide a general script loader cross-browser.

Since it is observed that the behavior in (a) is more detrimental (race-condition wise) for the case where dependencies exist, script loaders like LABjs had to find some way around this problem while still attempting the best possible parallel loading performance. However, the trick used is hacky and not completely reliable -- yet it is the best way to solve the use-case in <s>IE and </s>Webkit.

For Gecko/Opera, the concession was just (silently) made that the lesser-common use case of "as fast as possible" wasn't possible, but degraded fine to "insertion order execution", while keeping the parallel loading benefits.

<blockquote style="background-color: #EEEEEE">
Gecko's strict execution order creates dependencies between scripts which are unrelated and prevents the ability mitigate the impact of server outages / network latency. This is exacerbated by the fact that Gecko, unlike IE and WebKit, provides no mechanism to <b>remove</b> scripts from the execution queue.

Consider the case where JSONP is used to provide auto-completion. The user types "hello" and the JSONP request is made; however, the "currently" loading script is out-of-date as soon as the user modifies his search to "hello world". Gecko's algorithm requires the out-of-date request load and execute before the second request.
</blockquote>

Recently, Gecko landed a [http://hg.mozilla.org/mozilla-central/rev/a60414d076b5 patch] to the trunk that stopped Gecko's existing behavior of preserving execution order, making script-inserted script elements now execute in "as fast as possible" mode similiar to IE/Webkit. Unfortunately, the "workaround" used in IE/Webkit (described in the next section) for dealing with parallel loading and execution-order dependencies does not work in Gecko, which means presently the use-case in question is now broken in Gecko trunk/FF4 nightlies.

Moreover, Webkit recently landed a [http://trac.webkit.org/changeset/67245 patch] to the trunk that stopped Webkit's non-standard but long-held behavior (also used in the "workaround" described in the next section) of loading into cache script resources with an unrecognized "type" value, but silently not executing them. This behvaior (while hacky) is central to being able to address the use-case in question in Webkit, so at present, Webkit nightlies are now also entirely broken on the use-case (though in a different way than Gecko).

Both the Gecko change and the Webkit change are well-intentioned, as they are bringing the respective browser more in line with the HTML spec. However, what's really been demonstrated is that the HTML spec is not properly handling this use-case, and so the goal is not to address the browser issues raised with more awkward hacks, but to address the shortcomings of the spec first, and then encourage all browsers to adhere to such.

<blockquote style="background-color: #EEEEEE">
Considering Internet Explorer's readyState implementation provides a means of both parallel loading and preserving execution order can be achieved, perhaps its "readyState" property and onreadystatechange event should be included.
</blockquote>

=== Current Usage and Workarounds ===
To work around the limitation in IE/Webkit(prior to the above noted patch) of not being able to rely on script order execution for parallel loaded scripts, a "preloading" trick was developed. This trick relied on non-standard (but long-held) behavior in these browsers that a script-inserted script element with an unrecognized "type" value (such as "script/cache") would be fetched/loaded, but would not execute. This had the effect of loading the resource into cache, and then firing the "load" handlers to let the page know when the resource was completely in cache.

Assuming that the resource was served with proper caching headers, and was in fact in the cache, it could then be executed (nearly) immediately when it was the proper execution order time by re-requesting the same resource via another script-inserted script element with the proper "text/javascript" type value, pulling the resource from the cache and executing it, without another server round-trip.

Of course, the assumption of proper cache headers is a huge one, and not at all reliable. Some recent estimates by performance optimization specialists have suggested as much as 70% of scripts across the internet are not served with proper caching headers, which means that such scripts would be completely ineffective if loaded using this (or a similar) technique. The script resource would end up being loaded completely a second-time, and the "near immediate" execution would obviously be false, and thus race conditions would ensue.

It's important to note at this point that the new <link rel=prefetch> facility has been suggested as a better workaround, but it suffers the same ill-fated assumption of script cacheability. Still others have suggested "new Image().src=..." or the [http://www.phpied.com/preload-then-execute/ <object> preloading trick] suggested by Stoyan Stefanov. Again, these tricks unwisely assume cacheability, for the "preloading" trick to solve the use-case in question.

=== At Risk ===
Currently, there are several large/popular web sites which are either currently (or who intend to soon) use LABjs in such a way as to run afoul of the new Gecko and Webkit behavioral changes with LABjs failing to operate properly. It's important to note that the problems of race conditions can be subtle and hard to detect, and so merely loading up such sites and failing to observe overt failure is not sufficient.

Sites which are known to have LABjs loading techniques in place with currently broken (or susceptible to such breakage in the near future) behavior are:

* [http://twitter.com Twitter]
* [http://zappos.com Zappos]
* [http://vimeo.com Vimeo]
* [http://mefeedia.com MeFeedia]
* [http://blog.getify.com Getify Solutions blog (my blog)]
* [http://flensed.com flensed Flash+JavaScript browser shims (cross-domain Ajax, cross-browser cookies, etc)]

Rather than getting hung up in the syntax of usage in LABjs that is or is not going to break, it's best to just think of the problem this way:

Does a site need to load more than one script, at least one of which comes from a remote domain location (like a CDN), and for which among the scripts there's at least one execution-order dependency among them? If so, then that site is susceptible to the current/future breakage if the HTML spec (and browsers) do not address this use case.

A common example (in use on many sites) of such might be loading:

* jQuery from the CDN
* jQuery-UI from the CDN
* plugins and usage code in one or more local files
* Google Analytics from the Google domain

Note that the emergence of popular script frameworks and their hosting on public CDN's is leading to more and more sites loading scripts from both local and remote locations, and also to loading more files that have dependencies (rather than the practice of concat'ing all files into one file to avoid dependency issues).

Any site which fits a profile like the above, and which might currently (many do), or in the future want to, use a script loader to improve their loading performance, will fail to achieve what they want cross-browser and in a performant way, if the HTML spec (and browsers) do not address the use case.

=== Benefits ===
The benefits of addressing both behaviors directly (without "preloading" tricks and bad assumption reliance) have been implied in the above discussion, but in short are:

a) clear and simplified code for script loaders, which leads to easier use by authors of more pages, which in turn leads to better web performance (as demonstrated clearly by intelligent script loading techniques as compared to just simple <script> tags in HTML markup)

b) full access to either/both of the execution-order behaviors (as the author sees fit), regardless of browser

c) avoiding reliance on bad assumptions (like cacheability) as a sufficient way to address the use-case

=== External Discussions of this Feature ===

* <cite>[http://lists.w3.org/Archives/Public/public-html/2010Oct/0088.html W3C public-html email thread]</cite>

* <cite>[http://www.w3.org/Bugs/Public/show_bug.cgi?id=11295 W3C Bug #11295]</cite>

* <cite>[https://bugzilla.mozilla.org/show_bug.cgi?id=602838 Mozilla Bug #602838]</cite>

* <cite>[https://bugs.webkit.org/show_bug.cgi?id=50115 Webkit Bug #50115]</cite>

* <cite>[http://hsivonen.iki.fi/script-execution/ HTML5 Script Execution Changes in Firefox 4 Beta 7]</cite>

* <cite>[http://blog.getify.com/2010/10/labjs-w3c-brief-update/ LABjs and W3C... brief update]</cite>

* <cite>[http://blog.getify.com/2010/10/ff4-script-loaders-and-order-preservation/ FF4, script loaders, and order preservation]</cite>

== Proposed Solutions ==

=== My Solution ===
The current proposal most well supported from the email discussion thread, and the one which I feel makes most sense, is described here.

The HTML spec already defines the "async" attribute for parser-inserted script tags, which when set to "true", changes their execution order behavior to be like script-inserted script-elements (in IE/Webkit), which is that they load in parallel and execute "as fast as possible" (ostensibly because the author is expressing no dependencies between multiple such "async"-marked scripts). Parser-inserted script elements without "async" (or with it set to false) behave as before and expected, which is that they load in parallel but execute in order.

However, the HTML spec does not define the "async" property (or any such behavior) for script-inserted script nodes (such as those created by a script loader). Instead, the spec implies that "async=true" like behavior is always true for such script-inserted script elements.

What is proposed is:

a) Script-inserted script elements should have (and respect the value of) an "async" property which is basically identical to the "async" attribute for parser-inserted script elements. That is, script elements with the "async" property set to "true" will behave accordingly, as will script elements with the "async" property set to false.

Essentially, the proposal is to mirror the "async" attribute behavior of parser-inserted script elements as an "async" property on script-inserted script elements. This has the benefit of using an existing facility and extending it (from current spec) in a way that is sensisble and symmetric with its current definition.
<blockquote style="background-color: #EFEFEF">
The scriptgroup or `readyState` alternate proposals allow for dependency management to be done in high-level code. The singular syncrhonized execution queue proposed here introduces artificial dependencies, undermining some of the benefits dynamic script loading provides.
</blockquote>

b) Furthermore, to aid in "feature-detection" of such new behavior, the proposal is to have the default value for the "async" property of script-inserted script elements be "true" (and of course the associated behavior thereof).

There are two major benefits to (b). One is that it provides a way to feature test such new behavior by not just looking for the existence of the "async" property on script elements, but specifically that the default value is "true" (which is opposite of what it would currently/normally be). Secondly, defaulting to "async=true" behavior for script-inserted script elements would preserve the default behavior of IE and Webkit, meaning there'd be less of a chance of breaking existing web content in either of those two browsers.

It's also important to note that there is no implied or requested effect or dependency between script-inserted script elements and parser-inserted script elements -- the two types of scripts would load and execute in entirely separate behavioral sandboxes.

==== Proposal Amendment: Events ====
In addition to standardizing how scripts load and execute, it's also important to standardize the load and error events, and under what circumstances they fire, etc. Without reliable load/error events, the main proposal is not reliable and is thus unhelpful for the use-case.

A script-inserted script element must fire the "load" event only once, when:

a) immediately after the resource finishes loading, but before parsing/execution, AND

b) the script element loads any non-empty content (that is, it was a successful HTTP request), AND

c) the script element has either loaded from the remote location, or is loaded from the brower cache

Specifically, the script "load" event must come immediately between the script element finishing loading and the script element being parsed/executed. If the script resource successfully loads, nothing should interrupt the sequence of fininshing loading, the "load" event firing, and the script being parsed/executed.

A script-inserted script element must fire the "error" event only once, when:

a) immediately after a loading failure for the resource is detected (that is, an HTTP error received, such as 404, 500, 503, etc).

Either the "load" or "error" event, but not both, will fire, and only once, for every script-inserted script element.

NOTE: "load" and "error" events on script-inserted script elements must fire synchronously to ensure event reliability.

A case may be made for adding the "load" and "error" events as described here to parser-inserted script elements as well.

==== Processing Model ====
Script inserted script elements will have an "async" property that defaults to "true". If the author does not change the value, all such requested script loadings will be in their own "queue" and will default to "as fast as possible" execution behavior. For any script elements that the author sets "async=false", those scripts will load in a separate "queue", and will execute in insertion order only. Again, these two "queues" will operate strictly independent of each other.

==== Processing Model Details (without the event amendment) ====

When a script element node is created, if it is being flagged as parser-inserted, set its force-async flag to false. Otherwise, set its force-async flag to true. (Note that createContextualFragment, innerHTML and XSLTProcessor::transformToFragment-created scripts are not flagged as parser-inserted.) This flag setting happens before any attributes (even parser-set ones) are set on the node.

When a previously-created script element node loses its parser-insertedness, if the element doesn't have the async content attribute, set the force-async flag to true and false otherwise.

When a script element node obtains the async content attribute (via setAttribute, setAttributeNode, setAttributeNS, by the fragment parser or the XSLTProcessor adding the attribute, etc.), set the force-async flag to false. (Note that calling removeAttribute("async") doesn't modify the force-async flag.)

The async IDL attribute must behave as follows:
* Upon setting, set the force-async flag to false and then reflect the async content attribute.
* Upon getting, if the force-async flag is true, return true. Otherwise, reflect the async content attribute.

In step 13. of http://www.whatwg.org/specs/web-apps/current-work/#running-a-script before the case "If the element has a src attribute" add a case:
If the script has a src attribute and the async IDL property getter returns false,
The element must be added to the queue of ordered script-inserted external scripts of the Document of the script element at the time the running a script algorithm started.

The task that the networking task source places on the task queue once the fetching algorithm has completed must run these steps:
# If the queue of ordered script-inserted external scripts is empty or the first script in the queue of ordered script-inserted external scripts has not been fetched yet, abort these steps.
# Execute the first script in the queue of ordered script-inserted external scripts.
# Remove the first script from queue of ordered script-inserted external scripts.
# Goto step #1.

Modify step 5 of http://www.whatwg.org/specs/web-apps/current-work/#the-end to say:
Spin the event loop until the set of scripts that will execute as soon as possible is empty and the queue of ordered script-inserted external scripts is empty.

==== Limitations ====
The two behaviors being identified solve either the case where no dependencies exist, or where a linear dependency chain exists (and which the script elements can be requested to execute in that order). It is possible that some authors have a more complex non-linear dependency chain that they would like to express. This would obviously require a much more complex API and spec change, and since that use-case has not (yet) surfaced as a particularly main-stream request, I believe it would be overengineering to try to address it with this proposed change set.

In addition, it's been duly noted that it's undesirable (and potentially confusing/problematic) to intentionally build in the inconsistency of having the "async" attribute (for parser-inserted scripts) and the "async" property (for script-inserted scripts) have different default values ("false" for the attribute, "true" for the property).

It's also been a point of discussion whether or not such a spec change has enough "carrot" to entice the browser vendors (namely IE and Webkit) to implement the behavior. Moreover, there's been some concern that if the default value for the "async" property were made to be "false" (like the attribute) to be more consistent and conservative, then it would possibly give the perception to IE and Webkit of "losing" some performance to cut out their default "as fast as possible" behavior.

=== Alternate Proposals ===
One early proposal on the email list was to introduce an entirely new property like "ordered" which an author could add to a script-inserted script element to instruct the browser to put it into the queue of execution-order-preserving script loadings. While such a property would address the use case, it introduces another property and thus more complicates the issue. It also fails to address the current spec inconsistency (which is confusing to new comers) that "async" is not a present/respected property in mirror of the attribute of the same name.

Another suggestion was a "waitFor" property that would be added to script elements and would specify a list of one or more DOM id's of other script elements that the current script should "wait for" in terms of execution. Again, this would solve the use case, but in a more complicated way, and there are concerns that it would be too confusing for the normal use-case.

Several suggestions have come in the form of creating explicit "preloading" (similar to <link rel=prefetch>), but as described above, "preloading" to solve this use case is a non-ideal hack and highly susceptible to breakage if the script fails to be sent with proper caching headers.

It's also been suggested that since this type of behavior is somewhat complicated, it may be better to intentionally obfuscate or complicate any such facility in the HTML, so as to make the barrier-to-entry rather high and force users to know what they are doing before doing it.

It's been suggested that "defer" already preserves execution order. However, "defer" is only defined for parser-inserted scripts, and thus is not applicable to the use-case in question from an on-demand point of view. Also, "defer" scripts explicitly way for DOMContentLoaded, even if they're ready to execute sooner. So this is less than desired.

Yet another proposal is a "document.executeScripts()" API, where an author can specify multiple sets of scripts that can load in parallel and it will enforce their execution order. A variation on that same idea was to use the "importScripts" from the Web Workers spec, however "importScripts" is synchronous (undesirable performance wise, obviously). The main downside (besides extra API complication) to "document.executeScripts()" is that there seem to be quite a few script execution properties/behaviors (including "document.currentScript" and charset override) which would have to be duplicated into this API facility.

==== "Script Group" element ====
One recent alternate proposal bears some special consideration, as it seems like it might be a decent option (although certainly more of a radical change for the spec and for browsers to implement). But it has the appearance of being pretty straightforward and semantic for authors to use, perhaps even more so than using "async".

The proposal is to create a new HTML element, called perhaps <scriptGroup>, <collection>, etc. Specifically, this element must be able to be inserted wherever a <script> element can currently be inserted. The "script group" element is intended to signify that all script elements added to it must perserve insertion execution order. This element wouldn't have much (but still some, explained in a moment) meaning in a parser-inserted context, since parser-inserted scripts already preserve order among themselves.

An advantage of the "script group" element would be to give a direct and easy way to attach event listeners ("load" and "error") to the entire group, rather than having to internally track events for each element if all you care about is the final "load" event, for instance. In the case of event handling, the "script group" element would have perhaps some benefit even in parser-inserted (markup) context.

The element would need to have an "id" property, and possibly attributes for "load" and "error" events.

A variation on how to look at this proposal is that a "script group" element could have an attribute/property on it (perhaps called "ordered") which would allow the group to either be order preserved or not. This would make the "script group" element much more useful in the parser-inserted context, as it would sort of be a shortcut to setting "async=true" on all the child script elements.

The "script group" element might look like this:

<scriptGroup id="group1">
<script src="foo.js"></script>
<script src="bar.js"></script>
<script>
somethingInline();
</script>
</scriptGroup>

Or, with the "ordered" attribute to explicitly control ordering behavior for the group:

<scriptGroup id="group1" ordered="true">
<script src="foo.js"></script>
<script src="bar.js"></script>
<script>
somethingInline();
</script>
</scriptGroup>

<scriptGroup id="group2" ordered="false" onload="alldone();">
<script src="baz.js"></script>
<script src="far.js"></script>
<script src="zab.js"></script>
</scriptGroup>

While the "script group" element is definitely more complicated to define and implement, it does have some semantic advantages for authors, and it also would significantly reduce the internal complexity of script loaders like LABjs. It would give authors (either directly or through script loaders) the flexibility to group scripts together into one of the two aforementioned behaviors (execution "as fast as possible" or "in insertion order"), and to easily access both behaviors in the same page.

==== Explicit support for "text/cache" MIME type behavior ====
Yet another alternate proposal has been suggested in the [[Talk:Dynamic_Script_Execution_Order]] thread.

Essentially, the proposal is that <script> tags directly support being declared with a `type` value of "text/cache". The behavior would be that the script resource is fetched, as the load events fired, as normal, but that the script itself would not be executed. Then later, at the desired time, the script in that element could be executed by changing the `type` value from "text/cache" to "text/javascript".

The browser would probably need to keep track (via some internal flag) that the script node is only ever executed once. Also, it's an open question if such a "cached" script node should be able to have its script content modified before execution via the `text` property.

==== readyState "preloading" ====
Per the suggestion/comment added to the above [[Dynamic_Script_Execution_Order#Current_Limitations|Current Limitations]] section, it's been suggested that IE's current behavior with respect to the `readyState` property can adequately serve the use-case in question.

The idea is that IE will begin fetching into the cache a script resource as soon as the `src` attribute of the dynamic script element is set. But IE will not execute the script (even if it finishes loading) until the script element is added to the DOM. However, the `readyState` property of the element, combined with the `onreadystatechange` handler listening for changes, can detect when the script has finished loading, by receiving the "loaded" value.

In this way, a script loader could "preload" a set of scripts all in parallel, but control their execution order by delaying the appending of the element to the DOM until execution is desired.

[[Category:Feature Request|Dynamic Script Execution Order]]

Dynamic Script Execution Order

2010-12-14T21:53:30Z

Serverherder: /* Current Limitations */

This page is intended to formalize the discussion around an important but currently underserved use-case (in both spec and various browser implementations): the need for a dynamic script loading facility that can download resources in parallel but ensure that they execute serially in insertion order, for dependency reasons.

A long email thread on the W3C public-html list, which began [http://lists.w3.org/Archives/Public/public-html/2010Oct/0088.html here] and for which a recent message is [http://lists.w3.org/Archives/Public/public-html/2010Oct/0415.html here], has been discussing this problem, but the email thread is becoming unruly and hard to track, so this wiki page will now be the official location to discuss the topic.

Briefly, this issue has arisen because recent "nightlies" changes in both Mozilla Gecko and Webkit have broken the ability for script-loaders like [http://labjs.com LABjs] to be able to download scripts in parallel but ensure their execution order. As a result of the discussion, it's become apparent that both the spec for, and various current browser implementations around, dynamic script loading is incomplete in addressing this use case, and that some change needs to occur.

There is one main proposal that has surfaced from the discussions, with several other alternatives having been discussed. This page will try to distill the long email thread down and clearly present the main proposal, objections, and alternative suggestions.

Please feel free to join the discussion of this topic in the [[Talk:Dynamic_Script_Execution_Order]] area.

== Use Case Description ==
Script tags/elements can either:

a) appear in the HTML markup ("parser-inserted"), OR

b) be dynamically appended to the DOM using document.createElement() ("script-inserted")

Parser-inserted script tags, up until recent browser versions, had the undesirable performance behavior of loading and executing serially, blocking everything else while doing so. Recently, many browsers have improved the situation by loading the scripts in parallel, but still executing them in order.

On-demand (or dynamic) script loading has emerged in recent years for a variety of different reasons, most notably the performance improvements to address such concerns. It is desired by many different scenarios to be able to download scripts to a page completely independently of the loading of the rest of a page's resources, or even well after a page has finished loading ("on-demand").

Recent additions to HTML spec such as "defer" and "async" were intended to address the use-case for parser-inserted script elements, but their behaviors have been unhelpful for the on-demand loading use-case (script-inserted script elements).

Thus, script loaders (like [http://labjs.com LABjs]) were developed to give page authors an easy way to specify one or more scripts to load (regardless of when in the life-time of the page that loading is requested), and for as many of them as possible to load in parallel, and for those scripts to be loadable from any local or remote domain location, and for the script loader to be able to control the execution order (if the usage of the script loader's API expresses the need to) to preserve dependencies between the scripts.

Sometimes, dynamic script loading is used to load totally independent scripts, and thus "as fast as possible" execution is desired. Other times (and possibly more frequently), multiple scripts are loaded with some dependencies among them, requiring them to execute in a certain order.

What is needed is some facility by which a script loader can express that dynamic script loading either does or does not need execution order preserved among the queue of requested script loadings.

=== Current Limitations ===
Unfortunately, browser behavior around script-inserted script elements and their loading and execution behavior is splintered. There are, at present, two main camps of behavior:

a) in IE and Webkit (including Chrome), the default behavior for script-inserted script elements is for them all to execute in "as fast as possible" mode, meaning there's no guarantee about ordering. This effectively makes on-demand (dynamic) script loading impossible to work in parallel-mode if the resources in question have dependencies -- the only straight-forward way to handle things is to load each file and execute, serially, losing the parallel loading performance benefits.
<blockquote style="background-color: #EEEEEE">
I'm not sure if this is the case.

IE will start fetching resources without execution simply by setting the src attribute. Scripts will not execute, however, until they are added to the document. Since IE supports the readyState attribute and readystatechange event, it's possible to load scripts in parallel and execute them in order without resorting to invalid type attribute hack-ery.

<pre style="background-color:white" lang="javascript">
script= document.createElement("SCRIPT");
script.onreadystatechange= function(){
if(this.readyState == 'loaded')
/*
Network fetch is now complete, following
triggers synchronous execution.
*/
document.body.appendChild(this);
else if(this.readyState == "complete")
this.onreadystatechange= null;
}
script.src= "foo.js";
/* Network fetching begins now */
</pre>
</blockquote>

b) in Gecko and Opera, the default behavior for script-inserted script elements is for them all to load in parallel, but execute serially in insertion order. Technically, this makes it impossible to dynamically load independent script elements and have them execute in "as fast as possible" mode.

As described above, both behaviors are desirable under different circumstances, but each of the two camps provides only one behavior, and no way to straightforwardly achieve the other. This obviously creates a big nightmare interoperability-wise when trying to provide a general script loader cross-browser.

Since it is observed that the behavior in (a) is more detrimental (race-condition wise) for the case where dependencies exist, script loaders like LABjs had to find some way around this problem while still attempting the best possible parallel loading performance. However, the trick used is hacky and not completely reliable -- yet it is the best way to solve the use-case in <s>IE and </s>Webkit.

For Gecko/Opera, the concession was just (silently) made that the lesser-common use case of "as fast as possible" wasn't possible, but degraded fine to "insertion order execution", while keeping the parallel loading benefits.

<blockquote style="background-color: #EEEEEE">
Gecko's strict execution order creates dependencies between scripts which are unrelated and prevents the ability mitigate the impact of server outages / network latency. This is exacerbated by the fact that Gecko, unlike IE and WebKit, provides no mechanism to <b>remove</b> scripts from the execution queue.

Consider the case where JSONP is used to provide auto-completion. The user types "hello" and the JSONP request is made; however, the "currently" loading script is out-of-date as soon as the user modifies his search to "hello world". Gecko's algorithm requires the out-of-date request load and execute before the second request.
</blockquote>

Recently, Gecko landed a [http://hg.mozilla.org/mozilla-central/rev/a60414d076b5 patch] to the trunk that stopped Gecko's existing behavior of preserving execution order, making script-inserted script elements now execute in "as fast as possible" mode similiar to IE/Webkit. Unfortunately, the "workaround" used in IE/Webkit (described in the next section) for dealing with parallel loading and execution-order dependencies does not work in Gecko, which means presently the use-case in question is now broken in Gecko trunk/FF4 nightlies.

Moreover, Webkit recently landed a [http://trac.webkit.org/changeset/67245 patch] to the trunk that stopped Webkit's non-standard but long-held behavior (also used in the "workaround" described in the next section) of loading into cache script resources with an unrecognized "type" value, but silently not executing them. This behvaior (while hacky) is central to being able to address the use-case in question in Webkit, so at present, Webkit nightlies are now also entirely broken on the use-case (though in a different way than Gecko).

Both the Gecko change and the Webkit change are well-intentioned, as they are bringing the respective browser more in line with the HTML spec. However, what's really been demonstrated is that the HTML spec is not properly handling this use-case, and so the goal is not to address the browser issues raised with more awkward hacks, but to address the shortcomings of the spec first, and then encourage all browsers to adhere to such.

<blockquote style="background-color: #EEEEEE">
Considering Internet Explorer's readyState implementation provides a means of both parallel loading and preserving execution order can be achieved, perhaps its "readyState" property and onreadystatechange event should be included.
</blockquote>

=== Current Usage and Workarounds ===
To work around the limitation in IE/Webkit(prior to the above noted patch) of not being able to rely on script order execution for parallel loaded scripts, a "preloading" trick was developed. This trick relied on non-standard (but long-held) behavior in these browsers that a script-inserted script element with an unrecognized "type" value (such as "script/cache") would be fetched/loaded, but would not execute. This had the effect of loading the resource into cache, and then firing the "load" handlers to let the page know when the resource was completely in cache.

Assuming that the resource was served with proper caching headers, and was in fact in the cache, it could then be executed (nearly) immediately when it was the proper execution order time by re-requesting the same resource via another script-inserted script element with the proper "text/javascript" type value, pulling the resource from the cache and executing it, without another server round-trip.

Of course, the assumption of proper cache headers is a huge one, and not at all reliable. Some recent estimates by performance optimization specialists have suggested as much as 70% of scripts across the internet are not served with proper caching headers, which means that such scripts would be completely ineffective if loaded using this (or a similar) technique. The script resource would end up being loaded completely a second-time, and the "near immediate" execution would obviously be false, and thus race conditions would ensue.

It's important to note at this point that the new <link rel=prefetch> facility has been suggested as a better workaround, but it suffers the same ill-fated assumption of script cacheability. Still others have suggested "new Image().src=..." or the [http://www.phpied.com/preload-then-execute/ <object> preloading trick] suggested by Stoyan Stefanov. Again, these tricks unwisely assume cacheability, for the "preloading" trick to solve the use-case in question.

=== At Risk ===
Currently, there are several large/popular web sites which are either currently (or who intend to soon) use LABjs in such a way as to run afoul of the new Gecko and Webkit behavioral changes with LABjs failing to operate properly. It's important to note that the problems of race conditions can be subtle and hard to detect, and so merely loading up such sites and failing to observe overt failure is not sufficient.

Sites which are known to have LABjs loading techniques in place with currently broken (or susceptible to such breakage in the near future) behavior are:

* [http://twitter.com Twitter]
* [http://zappos.com Zappos]
* [http://vimeo.com Vimeo]
* [http://mefeedia.com MeFeedia]
* [http://blog.getify.com Getify Solutions blog (my blog)]
* [http://flensed.com flensed Flash+JavaScript browser shims (cross-domain Ajax, cross-browser cookies, etc)]

Rather than getting hung up in the syntax of usage in LABjs that is or is not going to break, it's best to just think of the problem this way:

Does a site need to load more than one script, at least one of which comes from a remote domain location (like a CDN), and for which among the scripts there's at least one execution-order dependency among them? If so, then that site is susceptible to the current/future breakage if the HTML spec (and browsers) do not address this use case.

A common example (in use on many sites) of such might be loading:

* jQuery from the CDN
* jQuery-UI from the CDN
* plugins and usage code in one or more local files
* Google Analytics from the Google domain

Note that the emergence of popular script frameworks and their hosting on public CDN's is leading to more and more sites loading scripts from both local and remote locations, and also to loading more files that have dependencies (rather than the practice of concat'ing all files into one file to avoid dependency issues).

Any site which fits a profile like the above, and which might currently (many do), or in the future want to, use a script loader to improve their loading performance, will fail to achieve what they want cross-browser and in a performant way, if the HTML spec (and browsers) do not address the use case.

=== Benefits ===
The benefits of addressing both behaviors directly (without "preloading" tricks and bad assumption reliance) have been implied in the above discussion, but in short are:

a) clear and simplified code for script loaders, which leads to easier use by authors of more pages, which in turn leads to better web performance (as demonstrated clearly by intelligent script loading techniques as compared to just simple <script> tags in HTML markup)

b) full access to either/both of the execution-order behaviors (as the author sees fit), regardless of browser

c) avoiding reliance on bad assumptions (like cacheability) as a sufficient way to address the use-case

=== External Discussions of this Feature ===

* <cite>[http://lists.w3.org/Archives/Public/public-html/2010Oct/0088.html W3C public-html email thread]</cite>

* <cite>[http://www.w3.org/Bugs/Public/show_bug.cgi?id=11295 W3C Bug #11295]</cite>

* <cite>[https://bugzilla.mozilla.org/show_bug.cgi?id=602838 Mozilla Bug #602838]</cite>

* <cite>[https://bugs.webkit.org/show_bug.cgi?id=50115 Webkit Bug #50115]</cite>

* <cite>[http://hsivonen.iki.fi/script-execution/ HTML5 Script Execution Changes in Firefox 4 Beta 7]</cite>

* <cite>[http://blog.getify.com/2010/10/labjs-w3c-brief-update/ LABjs and W3C... brief update]</cite>

* <cite>[http://blog.getify.com/2010/10/ff4-script-loaders-and-order-preservation/ FF4, script loaders, and order preservation]</cite>

== Proposed Solutions ==

=== My Solution ===
The current proposal most well supported from the email discussion thread, and the one which I feel makes most sense, is described here.

The HTML spec already defines the "async" attribute for parser-inserted script tags, which when set to "true", changes their execution order behavior to be like script-inserted script-elements (in IE/Webkit), which is that they load in parallel and execute "as fast as possible" (ostensibly because the author is expressing no dependencies between multiple such "async"-marked scripts). Parser-inserted script elements without "async" (or with it set to false) behave as before and expected, which is that they load in parallel but execute in order.

However, the HTML spec does not define the "async" property (or any such behavior) for script-inserted script nodes (such as those created by a script loader). Instead, the spec implies that "async=true" like behavior is always true for such script-inserted script elements.

What is proposed is:

a) Script-inserted script elements should have (and respect the value of) an "async" property which is basically identical to the "async" attribute for parser-inserted script elements. That is, script elements with the "async" property set to "true" will behave accordingly, as will script elements with the "async" property set to false.

Essentially, the proposal is to mirror the "async" attribute behavior of parser-inserted script elements as an "async" property on script-inserted script elements. This has the benefit of using an existing facility and extending it (from current spec) in a way that is sensisble and symmetric with its current definition.

b) Furthermore, to aid in "feature-detection" of such new behavior, the proposal is to have the default value for the "async" property of script-inserted script elements be "true" (and of course the associated behavior thereof).

There are two major benefits to (b). One is that it provides a way to feature test such new behavior by not just looking for the existence of the "async" property on script elements, but specifically that the default value is "true" (which is opposite of what it would currently/normally be). Secondly, defaulting to "async=true" behavior for script-inserted script elements would preserve the default behavior of IE and Webkit, meaning there'd be less of a chance of breaking existing web content in either of those two browsers.

It's also important to note that there is no implied or requested effect or dependency between script-inserted script elements and parser-inserted script elements -- the two types of scripts would load and execute in entirely separate behavioral sandboxes.

==== Proposal Amendment: Events ====
In addition to standardizing how scripts load and execute, it's also important to standardize the load and error events, and under what circumstances they fire, etc. Without reliable load/error events, the main proposal is not reliable and is thus unhelpful for the use-case.

A script-inserted script element must fire the "load" event only once, when:

a) immediately after the resource finishes loading, but before parsing/execution, AND

b) the script element loads any non-empty content (that is, it was a successful HTTP request), AND

c) the script element has either loaded from the remote location, or is loaded from the brower cache

Specifically, the script "load" event must come immediately between the script element finishing loading and the script element being parsed/executed. If the script resource successfully loads, nothing should interrupt the sequence of fininshing loading, the "load" event firing, and the script being parsed/executed.

A script-inserted script element must fire the "error" event only once, when:

a) immediately after a loading failure for the resource is detected (that is, an HTTP error received, such as 404, 500, 503, etc).

Either the "load" or "error" event, but not both, will fire, and only once, for every script-inserted script element.

NOTE: "load" and "error" events on script-inserted script elements must fire synchronously to ensure event reliability.

A case may be made for adding the "load" and "error" events as described here to parser-inserted script elements as well.

==== Processing Model ====
Script inserted script elements will have an "async" property that defaults to "true". If the author does not change the value, all such requested script loadings will be in their own "queue" and will default to "as fast as possible" execution behavior. For any script elements that the author sets "async=false", those scripts will load in a separate "queue", and will execute in insertion order only. Again, these two "queues" will operate strictly independent of each other.

==== Processing Model Details (without the event amendment) ====

When a script element node is created, if it is being flagged as parser-inserted, set its force-async flag to false. Otherwise, set its force-async flag to true. (Note that createContextualFragment, innerHTML and XSLTProcessor::transformToFragment-created scripts are not flagged as parser-inserted.) This flag setting happens before any attributes (even parser-set ones) are set on the node.

When a previously-created script element node loses its parser-insertedness, if the element doesn't have the async content attribute, set the force-async flag to true and false otherwise.

When a script element node obtains the async content attribute (via setAttribute, setAttributeNode, setAttributeNS, by the fragment parser or the XSLTProcessor adding the attribute, etc.), set the force-async flag to false. (Note that calling removeAttribute("async") doesn't modify the force-async flag.)

The async IDL attribute must behave as follows:
* Upon setting, set the force-async flag to false and then reflect the async content attribute.
* Upon getting, if the force-async flag is true, return true. Otherwise, reflect the async content attribute.

In step 13. of http://www.whatwg.org/specs/web-apps/current-work/#running-a-script before the case "If the element has a src attribute" add a case:
If the script has a src attribute and the async IDL property getter returns false,
The element must be added to the queue of ordered script-inserted external scripts of the Document of the script element at the time the running a script algorithm started.

The task that the networking task source places on the task queue once the fetching algorithm has completed must run these steps:
# If the queue of ordered script-inserted external scripts is empty or the first script in the queue of ordered script-inserted external scripts has not been fetched yet, abort these steps.
# Execute the first script in the queue of ordered script-inserted external scripts.
# Remove the first script from queue of ordered script-inserted external scripts.
# Goto step #1.

Modify step 5 of http://www.whatwg.org/specs/web-apps/current-work/#the-end to say:
Spin the event loop until the set of scripts that will execute as soon as possible is empty and the queue of ordered script-inserted external scripts is empty.

==== Limitations ====
The two behaviors being identified solve either the case where no dependencies exist, or where a linear dependency chain exists (and which the script elements can be requested to execute in that order). It is possible that some authors have a more complex non-linear dependency chain that they would like to express. This would obviously require a much more complex API and spec change, and since that use-case has not (yet) surfaced as a particularly main-stream request, I believe it would be overengineering to try to address it with this proposed change set.

In addition, it's been duly noted that it's undesirable (and potentially confusing/problematic) to intentionally build in the inconsistency of having the "async" attribute (for parser-inserted scripts) and the "async" property (for script-inserted scripts) have different default values ("false" for the attribute, "true" for the property).

It's also been a point of discussion whether or not such a spec change has enough "carrot" to entice the browser vendors (namely IE and Webkit) to implement the behavior. Moreover, there's been some concern that if the default value for the "async" property were made to be "false" (like the attribute) to be more consistent and conservative, then it would possibly give the perception to IE and Webkit of "losing" some performance to cut out their default "as fast as possible" behavior.

=== Alternate Proposals ===
One early proposal on the email list was to introduce an entirely new property like "ordered" which an author could add to a script-inserted script element to instruct the browser to put it into the queue of execution-order-preserving script loadings. While such a property would address the use case, it introduces another property and thus more complicates the issue. It also fails to address the current spec inconsistency (which is confusing to new comers) that "async" is not a present/respected property in mirror of the attribute of the same name.

Another suggestion was a "waitFor" property that would be added to script elements and would specify a list of one or more DOM id's of other script elements that the current script should "wait for" in terms of execution. Again, this would solve the use case, but in a more complicated way, and there are concerns that it would be too confusing for the normal use-case.

Several suggestions have come in the form of creating explicit "preloading" (similar to <link rel=prefetch>), but as described above, "preloading" to solve this use case is a non-ideal hack and highly susceptible to breakage if the script fails to be sent with proper caching headers.

It's also been suggested that since this type of behavior is somewhat complicated, it may be better to intentionally obfuscate or complicate any such facility in the HTML, so as to make the barrier-to-entry rather high and force users to know what they are doing before doing it.

It's been suggested that "defer" already preserves execution order. However, "defer" is only defined for parser-inserted scripts, and thus is not applicable to the use-case in question from an on-demand point of view. Also, "defer" scripts explicitly way for DOMContentLoaded, even if they're ready to execute sooner. So this is less than desired.

Yet another proposal is a "document.executeScripts()" API, where an author can specify multiple sets of scripts that can load in parallel and it will enforce their execution order. A variation on that same idea was to use the "importScripts" from the Web Workers spec, however "importScripts" is synchronous (undesirable performance wise, obviously). The main downside (besides extra API complication) to "document.executeScripts()" is that there seem to be quite a few script execution properties/behaviors (including "document.currentScript" and charset override) which would have to be duplicated into this API facility.

==== "Script Group" element ====
One recent alternate proposal bears some special consideration, as it seems like it might be a decent option (although certainly more of a radical change for the spec and for browsers to implement). But it has the appearance of being pretty straightforward and semantic for authors to use, perhaps even more so than using "async".

The proposal is to create a new HTML element, called perhaps <scriptGroup>, <collection>, etc. Specifically, this element must be able to be inserted wherever a <script> element can currently be inserted. The "script group" element is intended to signify that all script elements added to it must perserve insertion execution order. This element wouldn't have much (but still some, explained in a moment) meaning in a parser-inserted context, since parser-inserted scripts already preserve order among themselves.

An advantage of the "script group" element would be to give a direct and easy way to attach event listeners ("load" and "error") to the entire group, rather than having to internally track events for each element if all you care about is the final "load" event, for instance. In the case of event handling, the "script group" element would have perhaps some benefit even in parser-inserted (markup) context.

The element would need to have an "id" property, and possibly attributes for "load" and "error" events.

A variation on how to look at this proposal is that a "script group" element could have an attribute/property on it (perhaps called "ordered") which would allow the group to either be order preserved or not. This would make the "script group" element much more useful in the parser-inserted context, as it would sort of be a shortcut to setting "async=true" on all the child script elements.

The "script group" element might look like this:

<scriptGroup id="group1">
<script src="foo.js"></script>
<script src="bar.js"></script>
<script>
somethingInline();
</script>
</scriptGroup>

Or, with the "ordered" attribute to explicitly control ordering behavior for the group:

<scriptGroup id="group1" ordered="true">
<script src="foo.js"></script>
<script src="bar.js"></script>
<script>
somethingInline();
</script>
</scriptGroup>

<scriptGroup id="group2" ordered="false" onload="alldone();">
<script src="baz.js"></script>
<script src="far.js"></script>
<script src="zab.js"></script>
</scriptGroup>

While the "script group" element is definitely more complicated to define and implement, it does have some semantic advantages for authors, and it also would significantly reduce the internal complexity of script loaders like LABjs. It would give authors (either directly or through script loaders) the flexibility to group scripts together into one of the two aforementioned behaviors (execution "as fast as possible" or "in insertion order"), and to easily access both behaviors in the same page.

==== Explicit support for "text/cache" MIME type behavior ====
Yet another alternate proposal has been suggested in the [[Talk:Dynamic_Script_Execution_Order]] thread.

Essentially, the proposal is that <script> tags directly support being declared with a `type` value of "text/cache". The behavior would be that the script resource is fetched, as the load events fired, as normal, but that the script itself would not be executed. Then later, at the desired time, the script in that element could be executed by changing the `type` value from "text/cache" to "text/javascript".

The browser would probably need to keep track (via some internal flag) that the script node is only ever executed once. Also, it's an open question if such a "cached" script node should be able to have its script content modified before execution via the `text` property.

[[Category:Feature Request|Dynamic Script Execution Order]]