[whatwg] Proposal for separating script downloads and execution

>> I'm curious if we could apply some "limit" to the number of scripts that
>> will be simultaneously preloaded, at say 100 scripts for instance?
>
> I would be fine with that from an implementation standpoint; not sure
> about the author-facing aspect of it.

As one of the concerned web-authors, I can't see having much trouble (again 
as long as the limit is high enough not to cause likely deadlock in the 99% 
use-case), nor caring, that the browser had some edge-case limits in place 
to prevent true run-away.

Just taking a swag, what would you say is the highest number that limit 
could be (by default) that you could still feel reasonably comfortable is 
protecting from run-away? 100? 500? 1000? If the number is 10, this may be 
impractical. If the number is 100+, I think it's quite unlikely to affect 
any of the vast majority use-cases.

Just as a random thought (perhaps too crazy out-there)... if we were 
concerned about dead-lock if the limit is reached... could this be a browser 
warning dialog to the user, like it is in some where they warn about "long 
running scripts"... Something like "This page is attempting to load but not 
use a large number of script resources. Do you want to allow this to 
continue?" I dunno, that's probably crazy. But again, I think it's probably 
rare enough that I wouldn't worry too much if that was the fail-safe at the 
end of the line.



>> The goal (from my perspective) is to come up with the simplest proposal
>> that serves the use-cases. Simplest being defined in this particular
>> situation as the least amount of change to the spec, AND the least
>> amount of change to the browser that has by far the slowest release
>> cycle (IE).
>
> That last part is an important point, yes.

Some people on this thread I think don't give the pragmatism of IE's release 
cycle as much weight as I do. If that weren't a concern, I probably would 
have been more in favor of Nicholas' v2.1 (current) proposal, based on its 
cleaner semantics. Honestly, it's the IE question that causes me still to 
favor my own proposal. And that's not meant to be a knock on IE. It's just 
meant to recognize the reality of that situation, and try to dance around it 
and find some balance/compromise.

Right or wrong, IE9 is feature-complete, and any change to this mechanism is 
almost certainly targeted for IE10 or later, which could very well be 1-2 
years away (or more). While we may, in practice, still be a ways off from 
full browser compat on this topic, I'm still fighting for the path that at 
least seems like it has the shortest path. I may be fighting the wrong 
battle, but that's my motivations thus far.


>> a) is execute() sync or async? what does this imply about if the script
>> being executed itself calls execute() on other script elements, and so 
>> on?
>
> Fair enough.  Seems to me that execute() should act just like inserting
> an inline script into the DOM does right now.  Browsers already have to
> handle that; they could just reuse this code.

There are some additional complications, I think. For instance, if a 
script.execute() call is made, and inside that script, it calls .execute() 
on its own script element... what does that do?

But yes, I agree that, as I've said many times in this thread, the more we 
can reuse of existing code and/or semantics, the better.


>> b) what does it imply about whether/when the event handler(s) would be
>> fired? If it's synchronous, are the event handlers also synchronous or
>> are they async? Are they fired before or after the execute() actually
>> does the executing of the script element?
>
> Which event handlers?

Well, script.onload for one. And for the IE crowd, also 
script.onreadystatechange. Oh, and the script.onerror handler needs to at 
least be considered as well. If both the execute and the event handlers are 
synchronous, I could see a situation where script.execute() causes a 
script.onerror to fire, which then calls another script.execute(), etc. I'm 
not specifically saying this type of thing is a problem, per se. I'm 
suggesting that there's quite a few questions that have to get thought about 
and spelled out. And we may not all agree completely on those answers, which 
is going to make getting .execute() even specified (much less implemented) 
quite a bit more involved.

If execute() were our only option, that would be the necessary task. If 
there's reasonable and simpler alternatives, which I think my (and Nicholas' 
current) proposals may very well be, I think the process should tend to 
favor that route, absent some strong reason (besides API preference) to 
force us down the more difficult path.


>> d) what are the semantics of if you call execute() on a script element
>> before it has finished preloading
>
> Good question, yes.

In the case of DOM-append-to-execute, this question is moot. In the case of 
execute(), it's an open question without full consensus, thus far.


>> e) what happens if a script's .text is modified before execute() is
>> called? What if a script element is cloned before execute() is called?
>> What if it's cloned after execute() is called?
>
> Also good questions.

Again, in the case of DOM-append-to-execute, these questions are already 
handled. In the case of execute(), we have to think about if the same 
semantics can cleanly be re-used or not. I don't know if we have consensus 
on them yet or not, frankly.


>> 3. If in the future we want to also support preloading of other
>> resources, like stylesheets for instance
>
> Preloading of stylesheets is already supported in at least Gecko.  Just
> mark them as disabled (or an alternate stylesheet not in the main set,
> which is the same thing in effect) and the sheet will be loaded+parsed
> but not applied.  Which is presumably what you mean by stylesheet
> preloading?

That's a good point I hadn't considered. Although I'm not sure at the moment 
if that is a spec'd thing or not, nor am I sure about the cross-browser 
support for it.

There's also the (minor) consideration that a true preloading would, 
ostensibly, possibly be avoiding or delaying the "parsing" part of the 
equation. I know much earlier in the thread we went around in circles quite 
a bit about whether or not the "parsing" of some resource is something that 
is useful to delay, or if authors should have any control over it.

AFAICT, the result of that part of the discussion was that explicitly 
delaying execution of a resource (and that being an implicit hint to the 
browser to consider delaying parsing) was a sufficient compromise. It would 
seem at first glance the same semantics for CSS 
preloading/parsing/"executing" would apply.

In any case, this is a rabbit trail we don't necessarily need to chase down 
right now. I was just mentioning that a little bit of future-thinking about 
other types of resource preloading was prudent, so as to not paint ourselves 
into a corner, where each type of resource has to have an entirely different 
(and perhaps awkwardly incompatible) way to do preloading. If images, CSS, 
and scripts (and perhaps other resource types) are all eventually 
preloadable in the same manner, that certainly greatly simplifies the 
complexity of a resource loader.



>> 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.
>
> I think you're overestimating the "wisdom" and "thought through"

Perhaps I am overstating the intentionality behind it being added to the 
spec before. I wasn't around when it was added, so I don't know either way. 
I give the benefit of the doubt, though, that it wasn't haphazard or 
careless.

Also, the bigger point is that my proposal to follow existing IE precedent 
is not JUST as a compatibility hack, but it's more following the lead that 
some spec author (I presume Ian) laid down before.

My presumption, perhaps incorrect, is that it's easier to get existing 
wording in the spec modified/clarified/enhanced than it is to get entirely 
new concepts written and spec'd.



--Kyle

Received on Wednesday, 23 February 2011 10:16:25 UTC