[whatwg] Script preloading

[Alex Russell]

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

> > How is this any different from the case today when <script> elements are
> fetched and run in the situation where one 404's?
>
> Right now, without any script loader, AFAICT, if A loads fine, B 404's or
> 500's, and C loads fine, both A and C will run, and usually C will have
> lots of cascading errors because it assumes B ran when it clearly didn't.
>
> What I'm saying is that quite a few developers have repeatedly asked for
> LABjs to provide some relief to that, because they would like to be able to
> have code-driven logic that tries to gracefully handle such an error.


Ok, and I'm saying they shouldn't be asking LABjs to handle it, they should
be asking the devtools teams at browser vendors to give them ways to deal
with it. You're not going to be able to pause execution for code, implement
future breakpoints, or debug root causes for this sort of thing well from
script. You can do SOMETHING, but not with the fidelity that devtools can.


> As I said, some developers have expressed the desire to have a script
> loader be able to re-try a failed script load a few times.


We'll be able to do this from the Navigation Controller:
https://github.com/slightlyoff/NavigationController/blob/master/explainer.md


> Others have expressed the desire to have alternate fallback URL(s) if a
> script fails to load at its primary location.
>

Again, only the NC will have the power to really do that in userland.
There's no need to complicate Ian's proposals (or argue against them) on
the basis of these use-cases.


> The point is, normal <script> tags don't let devs do that AT ALL, and when
> they want to do such things, they hope that a script loader could give them
> that capability. Since LABjs currently relies on <script> elements in
> pretty much all cases, LABjs can't give them what they want.
>
> As far as I'm concerned, this is absolutely a *candidate* for a perfect
> silver-bullet next-generation script loading mechanism that handles all the
> complex use-cases under discussion thus far under discussion.
>
>
>
> > 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.
>
> As stated, this isn't as much about developers doing things in dev-mode,
> it's about them wanting to have more robust loading logic in their
> production installations that is capable of doing things like
> script-load-retries or script-load-fallback-URLs.
>
> Certainly developers asking LABjs for this don't care nearly as much
> whether other developers can effectively deal with the issue using their
> devtoosl as they care that their production website in front of end-users
> has the ability to respond more robustly, if they care that much in the
> first place.
>
>
>
> > 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 was suggesting if we're inventing a new mechanism called `depends` as
> Jake has suggested, it would be nice if that new mechanism was made
> sensitive to things like "did the script load successfully (non 4xx/5xx)",
> and even better if it could also be sensitive to things like "the script
> load successfully, but was there an uncaught error thrown during its main
> execution?"
>
> The more sensitive the mechanism is, the more capable it would be to
> handling the use-cases these developers care about.
>
>
>
> > 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.
>
> Why so hostile? Isn't it quite apropos/germane to discuss HERE what
> real-world developers want to do (and cannot do currently!) in their code
> as it relates to script loading?
>
> I exhaustively listed out 11 other use-cases of things I care about, as a
> script loader author/maintainer. Are none of those use-cases apropos? Then
> I noted an additional 12th use-case here that I may not personally care as
> much about, but dozens of times developers have filed issues against LABjs
> begging/insisting for.
>
> It appears that some people care enough about production loading
> robustness that they go to extraordinary efforts in their code to detect
> and respond to such conditions. I felt like those many requests to LABjs
> (and I'm sure other script loaders get similar requests) was evidence
> enough that there's a valid use-case to consider and I was just bringing it
> up for such consideration.
>
>
>
> --Kyle
>
>
>