>> As I noted above, what we need to know (and I guess we need to know this 
>> from all browsers) if there's a *guarantee* of a->b->c execution order (even 
>> if all 3 are executing async)
> 
> I don't believe there is such a guarantee, unless the spec spells it out 
> explicitly.


The `async=false` stuff in the spec talks about dynamically loaded (not parser 
loaded) scripts going into a queue so they are downloaded in parallel, but 
executed in request-order from the queue.

So, in my aforementioned `execScript(..)` function, if it also set `s.async = 
false`, I believe that would opt all of the scripts into the async queue.

function execScript(l) {
  var s = document.createElement("script");
  s.async = false; // <-- insert this to get ordered-async
  s.src = l.href;
  document.head.appendChild(s);
  return s.loaded();
}

Even though all of them would, at that point, be strictly loading from cache, 
it should still have the effect of ensuring they execute strictly in a->b->c 
order, correct?



-----


One downside to this is that there were use-cases where the single "queue" that 
this spec mechanism created were not sufficient, such as loading a group of 
scripts for widget A and another independent group of scripts widget B, and not 
wanting A or B to block the other.

If all of those scripts were set with `async=false` and thus all put in that 
single queue, widget A's scripts could block widget B's scripts, which sorta 
fails that use-case.

However, it would probably only be a slight delay, as you wouldn't (in the 
previously mentioned code pattern) add the <script> elements to the DOM (and 
thus the queue) until after all the <link rel=preload>'s had finished loading, 
so it would only be parsing/execution that blocked, not downloading.

Execution is already an implicit blocking, as the engine can only run one 
script at a time, so actually, it's just a concern of potential parsing 
blocking other parsing.

The question is whether `async=false` scripts in the queue can be parsed in 
parallel (unblocked from each other) on the background threads, as you said, or 
whether being in that async=false queue means that both parsing and execution 
happen "in order", and thus could cause long parsing of widget A's scripts from 
blocking parsing of widget B's scripts?

However you slice it, I think it would cause *some* delays between widget A and 
B (aka, not totally independent), but it would in general be far less delays 
than what we have currently, which is that downloading blocks in that queue. So 
that seems like a big (if not complete) win. :)



--Kyle






Reply via email to