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
