[whatwg] Proposal for separating script downloads and execution

[Glenn Maynard]

On Sun, Feb 13, 2011 at 6:44 PM, Kyle Simpson <getify at gmail.com> wrote:

> I've compiled a WHATWG Wiki page detailing both Nicholas' most recent (and
> simplified) proposal (v2.1), as well as mine:
>
> http://wiki.whatwg.org/wiki/Script_Execution_Order_Control
>
> In essence, the two are somewhat converging, though are still distinct in
> important ways. Nicholas's proposal now includes relying on DOM appending to
> execute a script (instead of using a new `execute()` method), in agreement
> with my proposal.
>

This change wasn't mentioned here, and introduces a lot of problems.

- <script onerror> is only dispatched for fetch errors, not syntax errors,
which makes error detection harder.
- If the called script throws an exception, the synchronous execute() model
allows the exception to be raised by execute().  With this model, they go
straight to the browser and they're much harder to detect.
- It makes synchronous execution impossible, which is a major limitation.
Your example code will call successCallback *before* the scripts are
actually executed, not after[1].  Also, due to the above, your example code
will call successCallback in both of the above cases: if the script fails to
parse, and if the script throws an exception.
- The scripts won't be executed immediately if there are already any scripts
on the "list of scripts that will execute in order as soon as possible";
they'll be deferred until it's their turn.  You need to set "async" to make
sure that doesn't happen.  However, that causes the "set of scripts that
will execute as soon as possible" to be used, which is unordered--the
scripts won't necessarily be added in the order you're inserting them.
You'd have to add one, wait for onload, then add the next, and so on, which
is much more cumbersome.

These issues are why I preferred execute() over readyState.  Removing it
introduces all of them to the preload proposal too.


Moreover, the strict reading of Nicholas' proposal is that a browser should
> not preload a script resource if the `preload` property is not set to
> `true`. This has two implications:
>

Maybe this was changed since you sent this mail, but: "When preload is
false, the user agent may download and execute the external script according
to its normal behavior."  Setting preload to true requires preloading, but
leaving it at false should change nothing.


[1] Note that FF3.6 does execute a script immediately when it's inserted
into the document, if the script is cached.  I'm pretty sure that's a bug.
Whether due to a bugfix or simply being masked due to changes in cache
behavior, it doesn't seem to happen in FF4.

-- 
Glenn Maynard