[whatwg] Script preloading

[Alex Russell]

On Thu, Jul 11, 2013 at 9:41 PM, Kyle Simpson <getify at gmail.com> wrote:

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

How is this any different from the case today when <script> elements are
fetched and run in the situation where one 404's?

And why is the fix not a "stop on first script error" devtools option
rather than a change to the intrinsics for loading? This is the usual
recourse for most debuggers. Or are you saying we should be able to detect
(via HTTP status code? some other mechanism?) that a script load as
"failed" before we even attempt to run the code which might depend on it?

I'm unsure how any of this is apropos to the debate at hand. Changes to
this proposal seem entirely the wrong place to be dealing with this sort of
failure/recovery issue.


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