[whatwg] Proposal for separating script downloads and execution

[Glenn Maynard]

I'm losing track in the noise of what the fundamental disagreements are--if
there even are any.  I think the original proposal is a very good place to
start:

- Add a "noexecute" attribute to SCRIPT, which instructs the browser to
retrieve the script without executing it.  noexecute implies async.
- Add an event triggered when the script finishes loading from the network,
indicating that it can be executed; eg. "load".
- Add an "execute" method to SCRIPT elements.  This executes the script
synchronously.  This can only be called for noexecute scripts, and can only
be called after the "load" event has been fired.
- If the script fails to parse, execute() raises an exception.  If the
browser was parsing the file asynchronously, reporting the error is deferred
until execute() is called.

The key points of this:

- It doesn't in any way restrict when the browser can actually parse the
script.  It's free to do so when the file finishes loading, when execute is
called, or any time in between.  Ideally, browsers would parse scripts in an
idle background task, pushing it to the foreground if execute is called
before it finishes.  (In theory, if Javascript parsing is single-pass, it
could even be done progressively as the file downloads, to lower latency.)
Browsers can already do all this with <script defer>; I don't know if any
do.
- The "scripts in comments" hack would be unneeded.  That's an unpleasant
hack, because it will both prevent browsers from caching compiled scripts,
and prevent scripts from being compiled in the background.  Specifying a
bogus file type also has these problems.
- Just for comparison: <script src="path.js" noexecute
onload="this.execute()"> seems roughly equivalent to <script async>, and
like async, falls back on immediate loading if noexecute isn't supported.
<script defer> could be implemented in terms of this as well.
- Since execute() is synchronous, anything it installs becomes available to
the caller immediately.  This may simplify script loaders, among other
things.
- The event name "load" follows the Progress Events spec.  If there's actual
demand, the rest of that interface could be applied later on.  I think this
is much clearer than a readyState-based interface.
- Support for this API is indicated by the presence of the "execute"
function.

As a side note: none of this addresses doing any of this from workers, which
have a completely different API for loading scripts.  Maybe none of the use
cases apply to workers.

-- 
Glenn Maynard