> 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. 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. 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) 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". :) I don't see an MDN page entry for `Navigation Controller`. 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
