[whatwg] Script preloading

[Kyle Simpson]

I'm still going to respond, in detail, with code comparisons, to Jake's suggestions that the other proposals besides mine handle all my stated use-cases.

However, before I do that, just to document for posterity, I just recalled another use-case which is a feature very frequently requested of LABjs, but is impossible with the current web platform. It's so common, I'm not sure why I forgot it in the other list, except perhaps sheer exhaustion.



12: Use-case: you have a string of scripts ("A.js", "B.js", and "C.js") loading which constitute a dependency chain. A must run before B, which must run before C.

However, if you detect an error in loading, you stop the rest of the executions (and preferably loading too!), since clearly dependencies will fail for further scripts, and the errors will just unnecessarily clutter the developer console log making it harder to debug.

One reason developers want this ability to pause/abort part of a chain of dependencies is the idea of "graceful recovery", where they could re-try the failed download again a few times, or perhaps try fallback URLs for a script, etc.

In any case, the desire is to stop C from running if B fails to load, for whatever reason.

In fact, some developers have even requested to be able to stop the chain and prevent further executions if the script loads, but there's some compile-time syntax error or run-time error that happens during the execution. For them, it's not enough for B to simply finish loading successfully, but that it must fully execute without error.

Generally speaking, separate JS files are treated as separate programs and are NOT prevented from executing if there's an error running a previous file. These developer requests are that they'd like script loaders to be able to give them that "stop the presses!" sort of error handling which they currently do not have.

From my observation of Jake's proposed code, the former part of this use-case seems possible, assuming `dependencies` would fail to match on a script which resulted in a load error (4xx, 5xx). There would be the extra complication that the script loader might switch to an alternate fallback URL for a script, in which case it'd have to go find any <script> elements waiting on the previous (failed) URL and update their `dependencies` list to the new URL.

However, it's less clear to me if `dependencies` would fail a match on a script that loaded "successfully" and started trying to run, but had some uncaught error happen during compile or execute? If so, fine.

Would that also mean that if the script loader were to retry (either with same or alternate URL) B, and that were to succeed finally, then C would then recognize that eventual success (in spite of previous failures) and run as expected? If so, fine.

If however `dependencies` can't be made sensitive to unerrored-execution, and there's no other event that a script loader can intercept **between** B and C and have a chance to stop C from running (yet), then I think this would be a use-case not fully served by what I've seen so far.

Also, there's the question of what it would mean/tak to "stop C from running (yet)". Perhaps the suggestion is to remove C's <script> element from the DOM for the time being? Would that actually be sufficient to prevent it from executing (even if it had already finished loading and was just paused waiting)?

Or perhaps the suggestion would be to temporarily change C's `dependencies` list to have some selector in it that's made up and not possibly fulfilled, like a made up/impossible script URL, so that C remains paused, until a later time when the script loader can come back and set the dependencies list back to something sane so that C can resume?





--Kyle