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