[whatwg] Proposal for separating script downloads and execution

[Kyle Simpson]

>> Again, I think the spirit we all share is to find the simplest proposal 
>> that gets the job done, and introducing a new .execute() concept raised 
>> more questions than it purported to solve.
>
> The last dozen or two messages were regarding your rabbit hole, which
> raised serious issues.

"Serious issues"? As far as I know there was only one issue recently raised: 
"what happens in the run-away case where someone preloads 10,000 scripts?" 
First of all, I don't think that particularly qualifies as "serious", 
because it's an extreme corner case at best. There was no evidence or 
argument for it being a valid use-case. It's clear that the concern is only 
for the accidental run-away.

Now, it IS obviously important to browser implementers, so we rightly 
explored it. But, with relatively little fuss/disagreement, the simple 
"limit" solution emerges at least at first glance as a feasible solution to 
that narrow specific problem. I haven't heard any tangible objections to why 
that wouldn't help ease the browser's concerns.

As for v1 of Nicholas' proposal, which you now champion, I have read the 
answers to (many of) the questions, but they aren't satisfactory as far as 
I'm concerned, so we can't exactly call those issues resolved. If you're 
trying to suggest that the questions about the original proposal are already 
fully resolved, I strongly disagree.

As you put it, that "rabbit hole" is neither as complete nor anywhere near 
as shallow as the single question rabbit hole we just explored for my 
proposal.

Moreover, the spirit of a "simple proposal" is not just about how many 
questions a proposal raises, but the actual simplicity of the eventual 
solution itself. I maintain my proposal is the simplest of the (now 3) 
proposals being discussed, because it has fewer moving parts. As a script 
loader author, I favor an "API" that is simpler to code against (as long as 
it serves all the use-cases), and one that, where possible, borrows on 
precedent of existing code. Since pretty much all script loaders already 
deal with checking `readyState` and `onreadystatechange` (because IE<9 
didn't support `onload`), it's easier to wire in a preloading solution based 
on *that code precedent* than it is to implement an entirely new paradigm 
with `preload=true`  or `execute()` kinds of semantics.

Thus I stand by my assertion that my proposal is more simple than v1 of 
Nicholas' proposal.


>>  c) does this run the risk of going afoul of the same issue that tripped 
>> of Firefox with their synchronous execution of inline script elements 
>> (that jQuery used for global-eval)?
>
> I don't know how an opt-in API that doesn't yet exist and which nobody
> is using can run afoul of existing code, so you'll need to be more
> specific.

I don't know all the details myself, perhaps Boris or Henri (Mozilla) could 
shed more light. But I *do* know that what prompted Firefox to stop 
enforcing insertion-order on dynamic scripts (which led to breaking LABjs 
and the whole "async=false" proposal and adoption) back in the fall was 
specifically something to do with problems of guaranteeing (or not?) 
synchronous execution of inserted script elements. Apparently, this was 
causing issues for jQuery and their global eval.

All I'm raising is that this is a relevant issue, at least for Mozilla, 
which has been dealt with recently, and it's prudent that we check to make 
sure that specific sync or async execution of scripts (in Glenn's and 
Nicholas' supported proposals) isn't going to create problems for their 
existing mechanisms, which have already been the recent subject of some 
changes and problems.


>>> I sympathize with that, since they're aiming to improve the likelihood 
>>> of
>>> being implemented--but the precedent it's drawing on seems like a bad 
>>> one,
>>> which should be treated as a compatibility hack rather than a precedent 
>>> for
>>> new APIs.
>>
>> I strongly disagree with this characterization, based solely on the fact 
>> that the wording of the current spec already says to do exactly as I'm 
>> proposing. That's not a "compatibility hack", that's further 
>> standardizing the wisdom that the spec writers already thought through 
>> and codified.
>
> There's no need to load images that aren't in the DOM, since you can
> simply add them to a hidden container in the document.  Loading images
> that aren't in any document avoids breaking existing pages--a
> compatibility hack.

I'm not basing my arguments for my proposal solely, or even remotely, on 
Image preloading. It's a side issue that Image preloading ALSO works this 
way -- nothing more than a tangential side note that it fits somewhat in 
consistency with how Image preloads, and that also CSS preloading with 
<link> *could* perhaps work the same way. If *that* is what derails support 
for my proposal, just forget they were even brought up.

What I'm really basing my argument on is the precedent of `readyState` in 
the XHR object (for event handling), the spec wording that specifically 
describes as a suggestion the preloading flavor from my proposal, *and* IE's 
implementation of that exact preloading algorithm. Those 3 arguments stand 
alone regardless of what Image does or does not do.


> It's odd to assume, in an architecture bogged
> down in so much backwards-compatibility, that everything it does is
> good precedent.

No one has yet given cause that it's bad precedent (other than 
opinion/preference). They have expressed distaste. But, in the absence of 
tangible arguments of how it's flawed, yes, I'm asserting it is reasonable 
precedent to build upon.

It's clear there are some people on this thread who do not like my proposal. 
I understand that. But I am only hearing hand-waving of preferences thus 
far, rather than real arguments against it. Expressing an opinion that 
something seems "hacky" is not much of a valid argument.


-----

I want to move this thread forward instead of digressing into yet more side 
tracks. So, I want to summarize the specific outstanding cons of my proposal 
(the pros have been stated already numerous times):

1. The feature-detect is weaker than the alternative proposals. it's 
workable, but it's admittedly not quite as semantic or ideal as the others. 
Granted. That's part of the tradeoff my proposal requires. But, I don't see 
how "less-than-ideal" becomes "show-stopper" (which it seems to have for 
some on this thread).

2. Preloading itself (regardless of method) IS subject to (accidental) 
misuse, which can create the run-away scenario Boris was concerned about. My 
proposal just makes it more likely to accidentally trip over that problem, 
by making the behavior automatic rather than opt-in. Agreed. The internal 
queue-limit for preloading (or even the user prompt) mitigates the severity 
of that corner case. So does proper documentation, education, and 
evangelism.

Other than those 2 issues, and a variety of subjective preference opinions 
of what is "hacky" and not... what else is outstanding as an actual 
fault/weakness of my proposal?

Glenn and Nicholas, will you each do the same kind of honest summary 
assessment of the pros/cons for your respective proposals, for the benefit 
of the thread?


> Hmm.  Here's a related idea:
>
> - Add an...

I don't think this thread is going to benefit from yet a 4th proposal. I 
think the way forward to any kind of solution is to attempt to converge, not 
diverge.

Or perhaps this issue just can't be solved in this wider audience thread, 
but needs to be referred to some sort of "working group" committee? I have a 
group in mind that could tackle that, if the powers that be think we've 
reached the end of feasibility in this current thread?



--Kyle