Re: [whatwg] Script preloading

On Fri, Jul 12, 2013 at 4:31 PM, Kyle Simpson <getify@gmail.com> wrote:

> > 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.
>
> I'm not sure why you keep focusing on this being a devtools centric
> question, because I think you're missing the point.
>
> The developers that are asking for these features from LABjs are NOT
> asking for the capability to debug what's going on with failed loads while
> testing their app in their development environment. IF what they're trying
> to do is diagnose and fix such failed loads while developing their app,
> then certainly that would squarely be a devtools type of task.
>
> LABjs also has a debug-build available, and it has certain extra tracing
> going on inside it when used, that aids developers in understanding, from
> its perspective, what is going on as things proceed through loading. That
> debug mode, in addition to whatever great devtools that exist or will
> exist, are all fantastic ways for developers to work on and fix problems.
>
> ***
> But all that is ENTIRELY ORTHGONAL to what the developers are actually
> presently asking from LABjs.
> ***
>
> They are asking, repeatedly, for the ability to have logic deployed in
> their *production* builds, which sits in front of end users which have no
> knowledge of or relation to any developer tools in whatever browser they
> use. Certainly, these developers are not interested in whether or not their
> end-users happen to be in a browser that has devtools, because end users
> don't care about devtools, and the developers who do care aren't actually
> using the user's browser anyway.
>

Ok, I think I understand what you're saying now.


> At this point, whether or not a browser has certain devtools is entirely
> irrelevant to what the developer wants from LABjs.
>
> What seems to be their mindset and internal narrative is this:
>
> "OK, no matter how good we are at figuring out how to build a bug-free
> app, we rely on third-party external resources that we don't control. We
> cannot guarantee that our request for 'jquery.js' from the Google CDN will
> actually work. It should work. It usually works. But it doesn't always
> work. Sometimes Google goes down. Sometimes the DNS lookup fails. Sometimes
> a proxy server misbehaves. Sh$$ happens. SO! We'll just accept that fact.
> We look at our RUM logs and we see that about 2% of our users experience
> one of these dead page loads. But, hey, I've got an idea, how about we try
> to write code into our production code which detects when something like
> that happens, and tries to gracefully recover, if possible, to maybe reduce
> the 2% down to 1%. Yeah, that's a good idea. How do we do that? Oh, I know!
> We're already using a script loader. Let's have that script loader tell us
> when `script.onerror` fires, which tells us that a script load failed
> (right!?!?), and we'll just re-request it from a fallback location on our
> own CDN. Sounds like a plan. Can you file a feature request at LABjs for
> them to expose when `script.onerror` fires? It'd be great if it just could
> automatically re-try or fallback to another URL. Yeah, that sounds cool.
> Sure, will do."
>
> I understand clearly at this point that you don't agree with their
> mindset. I understand you think their desire is misguided. I admit
> sometimes I am skeptical of the efficacy of such efforts.
>

It's not scepticism at that level that I'm expressing. Accepting everything
you just typed out (AT EYE-WATERING-LENGTH), changes to Ian's proposal are
still a poor place to attack the issue. The Navigation Controller can give
you everything you want here and more. It's the right hammer for this
particular nail, not dependency attributes.


> But respectfully speaking, your opinion is not the only one that matters
> here.
>
> Who are we to tell some in-good-faith developer that they are objectively
> WRONG to hope their script loader could not only LOAD scripts but RELOAD or
> ALTLOAD scripts. Think about the conceptual and semantic there. It's a
> pretty sensible expectation for most non-browser-author devs.
>
>
>
> > We'll be able to do this from the Navigation Controller:
> https://github.com/slightlyoff/NavigationController/blob/master/explainer.md
>
> Never heard of it before. Thanks for the link.
>
> But I don't see how the idea that this may (likely) happen (someday)


We're working on implementing it in Chrome. So yes, both likely and soon.


> automatically moots the discussion at hand. For you to fairly exercise
> some sort of veto vote over what we discuss, which it seems like you're
> trying to do, you've gotta come to the table with some real tangible thing
> that's standardized (or clearly headed that way) and ready to evaluate for
> fitness to the use-cases.
>
> I glanced through (it's long, haven't digested it yet) and didn't
> immediately see a section called "RETRYING AND FALLBACK LOADING". :)
>

It's unfair of you to expand the scope of a proposed feature to include
your pet issue when, logically, it can be separated. See what we both just
did there?

Better to ask *how best *to accomplish our goals, not fight over where to
do that. And that's the spirit I offered the NC in (and pour my work into
it over). Happy to discuss NC over at the github repo, FWIW.


> I don't see an MDN page entry for `Navigation Controller`.


And there's one for these new attributes here? Sorry, but rhetorical games
are not how you will win any fights here.


> I can't find "Navigation Controller" on http://caniuse.com yet. So far,
> the only google result I've found for it is your writeup. So having only
> seen it for a few moments as of the writing of this email, and finding no
> other evidence about it, it's hard to judge if it's a valid alternative for
> the requested use-cases or not.
>
> Would you be able to make a gist showing how a script loader like LABjs
> could use Navigation Controller's API to facilitate the retry/fallback
> use-case?
>
> Short of such code, I'll take your word that eventually it might serve the
> use-case. But that's about all I can clearly say thus far.
>
> And I don't think that's strong enough evidence to swat down my use-case
> or a present fair discussion of it.
>
>
>
> > Again, only the NC will have the power to really do that in userland.
>
> It's convenient for you to assert that ONLY this API will have that
> control. But under what authority can you assert that no other mechanism in
> the web platform could possibly ever serve the intended needs? Is there
> some security mandate I'm unaware of which says only "Navigation
> Controller" is trustworthy enough?
>
> -----
>
> I don't like Jake's proposal. I've expressed my distaste for it. If it's
> based on something Ian suggested, I don't like Ian's suggestion either.
>
> It's fair for me, in my examination of those proposals, to state things
> that I (and other real world developers) would like to do, and point out
> where those proposals might fall short of what we want.
>
> Here's the crux of my questions presently:
>
> Neither Ian nor Jakes proposal variations are CLEAR on if the
> `dependencies` attribute would or would not be sensitive to failed loads
> (or compile-time/run-time errors). Certainly there has to be AN ANSWER to
> that question. Is it sensitive at all? If so, to what extent?
>
> Let's be clear here. I'm not proposing we have such a mechanism whose
> sensitivity is relevant. That's what Jake and Ian are proposing. I'm just
> asking to clarify their proposal, so that I can evaluate if their proposal
> meets my use-case needs.
>
>
> ***MY PROPOSAL*** is not really too concerned with those issues, because
> in my proposal, I (the script loader) am fully in control of when the next
> script is set eligible to execute, so I can detect whatever load or compile
> or runtime errors I want, at any point, and if I want to, I can just NOT
> EXECUTE THE NEXT SCRIPT. That gives me, the script loader, ultimate control.
>
> To me, that kind of complete flexibility in the hands of a developer is a
> good win.
>
> I would humbly submit, Alex (and Ian and Jake), my proposal is far less
> intrusive on the web platform, and far less pesky about such questions of
> sensitivity, than the proposals you are advocating for. So if you're
> annoyed that I would ask to clarify what those sensitivies may or may not
> be, then perhaps you should just abandon those other proposals and support
> mine, which makes those questions moot.
>
>
>
> > There's no need to complicate Ian's proposals (or argue against them) on
> the basis of these use-cases.
>
> I disagree. I am advocating for the use-case on behalf of real-world
> developers, who I care about. I think it's worth discussion. I apologize
> that doing so seems to burden you.
>
>
>
>
>
>
> --Kyle
>
>
>
>
>
>

Received on Friday, 12 July 2013 18:13:19 UTC