[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