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