[whatwg] Proposal for separating script downloads and execution

[Kyle Simpson]

?> The ability to separate download and execution is a trend that has not 
only emerged, but continues to be explored. There are problems with the 
previous solutions, the biggest of which (in the case of #1 and #2) is the 
reliance on the browser caching behavior which may, in some instances, lead 
to a double download of the same script. It would be preferable for a 
standardized approach to achieve these goals.

Absolutely agree with Nicholas that this is a necessary (but I think more 
advanced) use-case in script loading. It's *especially* useful for the 
mobile web, where CPU utilization (the parsing/execution of scripts) must be 
carefully managed. For instance, you might want to take advantage of loading 
a bunch of code all at once, while the mobile radio receiver is still on in 
the initial loading, but then choose to execute them piece by piece as the 
user needs it.

Of course, in the desktop world, it's useful as well, as script loaders can 
use this technique to load multiple files in parallel, but execute them in a 
desired order (for dependency-sake). FYI: for *that* particular use-case, a 
solution has already been discussed, and, as I understand it, Ian has agreed 
to add it to the spec. I'm referring to the "async=false" functionality 
proposal that's been discussed in various forums for the past few months, 
and is now in implementation in FF4 and coming soon to Webkit.



> Add a new attribute to the <script> called noexecute (for lack of a better 
> term) that instructs the browser to download the script but do not execute 
> it. Developers must manually execute the code by calling an execute() 
> method on the script node.

I'm not particularly in favor of this proposal, mostly because the spec 
already has a mechanism listed in it (and indeed it's been implemented in IE 
since v4) for doing exactly this.

http://dev.w3.org/html5/spec/Overview.html#running-a-script

In step 12:
"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."

In other words, you can begin downloading one or more scripts (but not 
executing them) by simply creating a script element dynamically and setting 
its `src` property. The script will not be executed (even if it finishes 
downloading) until the script element is added to the DOM. In this way, you 
can easily create several script elements (but not append them to the DOM), 
and then when you want to execute them, you simply append them to the DOM in 
the order you prefer.

IE goes one step further, which I think is useful, which is to give a 
`readyState` (and `onreadystatechange` event handling) to the script 
element, which notifies the code of the state of this "preloading". Why this 
is useful is that you may choose to wait until all scripts have finished 
loading before starting to execute them. Being notified of when they finish 
loading (but not executing) can be a very useful addition to this technique.

The wording in the spec lists this idea as "may". I suggest that the 
discussion Nicholas has proposed should shift to discussing if the spec 
should:

1) change "may" to "shall" or "will" to move it from being a suggestion to 
being a directly specified thing (that way the other browsers besides IE 
have incentive to eventually include it)

2) consider also specifying (rudimentary/basic wording of course) a 
mechanism similar to or compatible with IE's existing `readyState` event 
emissions for the script tag, such that the progress of the "preloading" 
(script.src set but script not yet DOM appended) can be monitored if 
need-be.

The primary reason I'm in favor of this approach over the one Nicholas 
suggests is because it's already in the spec as a suggestion (less "work" to 
get it to fully specified) and because one browser has already implemented 
and proven the approach, a foundation upon which other browsers can move 
forward.


--Kyle