[whatwg] Script preloading

[Alex Russell]

On Fri, Jul 12, 2013 at 7:56 PM, Kyle Simpson <getify at gmail.com> wrote:

[ snip ]


> Again: my question (which remains unanswered), & the reason I stated the
> error/retry/fallback use case in detail, is whether or not the dependency
> attributes proposal, as put forth by Jake (and Ian) will or will not,
> factually speaking, have any sensitivity to the error conditions (network
> load error, compile error, run-time error) or not, or somewhere in between?
>

As per the existing outline, I don't see how it could have any
"sensitivity".


> If `dependencies` IS sensitive, in any way, then it clearly overlaps
> Navigation Controller, right? That may or may not be a good thing. If OTOH
> it has no sensitivity whatsoever, and it will trigger a subsequent waiting
> resource regardless of ANY particular network condition or result, that is
> vital information to know, as well.
>
> Either way, shouldn't we afford enough discussion here to discuss how
> little or how much, or if at all, that sensitivity would be? I certainly
> can't adequately judge the proposal in the absence of that information.
>
> Isn't it fair enough for me to inquire as to the actual nature of their
> proposal, given that they've asserted in no uncertain terms that it is
> fully sufficient for all my use-cases? Aren't I entitled to examine that
> with the assistance and participation of this list?
>
> None of that means I necessarily think that Navigation Controller is or is
> not ALSO suitable. I have no opinion on that yet. I stated the reasons why
> I have no opinion on it yet.
>
> Presenting an alternate proposal for one or more use-cases, as you have
> done, is fine. But that doesn't mean that it answers the questions I have
> about the other proposal, by Jake and Ian. Those pre-existing questions are
> my concern, presently.
>
>
>
> > We're working on implementing it in Chrome. So yes, both likely and soon.
>
> I look forward to seeing more great documentation on it as we've all come
> to appreciate from the Chrome and Developer relations teams.


I owe this list (and others) mail about it. Hoping to have that ready soon.


> > 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?
>
> Expand the scope? I am not expanding the scope beyond that which I've
> pushed for over and over again for 3+ years, this thread just being the
> latest incarnation. That others (like you) may come to this list with a
> pre-conceived notion of what is and is not "in scope" doesn't mean that me
> stating (in response to repeated appeals from Jake and others) at length
> the use-cases *I* care about is actually "expanding" that scope.
>

I think you missed the second sentence...


> Moreover, I am the originator, or at least one of them, of the "proposed
> feature", so I hardly think it's fair for you assert that I'm changing the
> game. In reality, I'm clarifying the "proposed feature" as it relates to my
> viewpoint, as an interested party acting in good faith. I'm recounting the
> substantial "prior art" in the discussions and discovery and
> experimentation.
>
> No, I'm not expanding the scope. You (and others) appear to want to be
> narrowing the scope that well pre-dates this thread.
>
> My scope (as it always has been) put simply: I want (for all the reasons
> here and before) to have a "silver bullet" in script loading, which lets me
> load any number of scripts in parallel, and to the extent that is
> reasonable, be fully in control of what order they run in, if at all,
> responding to conditions AS THE SCRIPTS EXECUTE, not merely as they might
> have existed at the time of initial request. I want such a facility because
> I want to continue to have LABjs be a best-in-class fully-capable script
> loader that sets the standard for best-practice on-demand script loading.
>
>
>
> > 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.
>
> Fair enough. That spirit is certainly appreciated.
>
> At the request of this list, I presented the use-cases as they stand, and
> as they always have. Any solution(s) which reasonably meet them would be a
> good candidate. We're seeking solutions, but we're doing so by exploring
> the fitness of various proposals.
>
> Over the years, I've championed no fewer than 3 different proposals for
> how I see a single coherent solution that solves all the use cases. That
> alone ought to demonstrate sufficient good-faith that I'm looking for
> solutions, not impetuously defending my "pet".
>
> Moreover, especially with this most recent proposal (<script preload>), I
> believe it not only sufficient to (trivially) handle *all* the use-cases
> I've presented, but also it is of the nature that it basically would answer
> nearly any other use-case you could imagine in script loading. Certainly my
> list is long but not fully exhaustive of every niche need/desire.
>
> In light of my proposal(s), none of which have been substantially refuted
> as inferior, I of course am advocating for whatever solution we end on to
> actually handle all the things my proposal would handle. Any proposal which
> substantially does not is, in my opinion, insufficient.
>
> You may want to contract the scope to leave some of my use-cases out of
> luck, but I'm entitled to avidly defend why I think that's unfair and the
> wrong approach.
>
> I am not married to my current proposal. If there is a single coherent
> solution, or some reasonable combination of them, which clearly will handle
> all the use-cases, and we can examine and compare WITH CODE (not just
> hypothetical ideas), as Jake suggests, great.
>
> But thus far, Navigation Controller is far behind the proposals of
> `<script preload>` and `<link rel=subresource> + <script dependencies=..>`
> in terms of being able to compare use-case coverage with actual practical
> code.
>

That's only your ignorance speaking. There are examples in the repo which
you can use to extrapolate examples, or if you a code snippet showing the
problem, either Jake or I can show how NC would address it.


> I look forward to you helping remedy that. :)
>
>
>
>
> --Kyle
>
>
>
>
>