[whatwg] Promise-vending loaded() & ready() methods on various elements

[Kyle Simpson]

>> 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