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

Jake Archibald jaffathecake at gmail.com
Fri Mar 14 14:03:15 PDT 2014


On 14 March 2014 20:10, Kyle Simpson <getify at gmail.com> wrote:

> Is <link rel=preload> going to fire this "loaded" event after it finishes
> pre-loading but BEFORE it executes (or, rather, BEFORE because it doesn't
> execute them at all)?
>

<link rel=preload> doesn't execute (you can use it to preload anything), so
loaded() fulfills before execution. With <script> loaded() fulfills after
execution.


> If you want to dynamically *preload* scripts (that is, you don't have
> <link rel=preload> tags in your initial page markup) later on in the
> lifetime of the page, is the story basically like this?
>
> Promise.all(
>    preloadScript("a.js"),
>    preloadScript("b.js"),
>    preloadScript("c.js")
> )
> .then(function(links){
>    return Promise.all.apply(null,links.map(execScript));
> })
> .then(function(){
>    alert("All scripts loaded and executed");
> });
>
> 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.

(btw, Promise.all takes an array, which nicely avoids the .apply stuff)

Jake.



More information about the whatwg mailing list