- From: Alex Russell <slightlyoff@google.com>
- Date: Fri, 12 Jul 2013 19:12:20 +0100
- To: Kyle Simpson <getify@gmail.com>
- Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>
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