?> 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.


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.


Reply via email to