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

[Kyle Simpson]

>> So, if that's how we think this would work, we need to understand how the
>> `execScript(..)` logic is going to be treated. Is creating a <script>
>> element dynamically and inserting it going to make sure that it either:
>> 
>>  a. executes sync
>>  b. executes async, but "a.js" will *definitely* execute before "b.js",
>> which will *definitely* execute before "c.js".
>> 
> 
> I'm hoping "a", but you tell me. Do you know what browsers do with a fully
> cached script? Is there consistency there? If not, yeah, you'll have to
> create a chain.

Regardless of (a) or (b), the simpler Promise approach (my first snippet) is sufficient, if and only if a->b->c is the  *guaranteed* execution order. That's the important part. If there's a chance the browser might do b->a->c (even if all were equally "ready" in the cache), then the pattern goes fubar and the uglier second syntax is required.

I'd say the first syntax is a bit verbose for what I was dreaming 4 years ago when I started asking for a simple script preloading mechanism, but it's just this side of acceptable. If we have to take the second approach, I say that's unacceptably more verbose/complex and falls short of my opinion of "everything we need for sane & versitile dependency loading".



>> Do you know what browsers do with a fully cached script?
> 
> "<script src=url>" is always executed async when inserted into the DOM, 
> cached or not.

Boris-

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) when they are added to the DOM in that order and all 3 are guaranteed preloaded first, by the <link rel=preload> tag usage? Is there ever a case where some other execution order than a->b->c would happen?




--Kyle