This, along with Ilya's proposed <link rel="preload"> (,
and JavaScript modules (
gives us everything we need for sane & versitile dependency loading.

Problem: Initialising an app on document ready, but also waiting for a
particular stylesheet to apply

Problem: Initialising an app after a non-module script

Taking the more complex use-cases from…

[Use-case Q:] Want to avoid executing a social-media script until the user
give some intent, although the script should be preloaded.

[Use-case S:] One plugin wants to execute "A.js" and "B.js" in order
following an interaction. Another wants to load "A.js" then "C.js" & "D.js"
in either order. "A.js" should only execute once. Scripts aren't written as
modules and out of developer's control.

[Use-case T:] Preload 2 scripts, execute one or the other on particular
Solution: Same as Q.

[Use-case U:] "A.js", "B.js", "C.js" - load them in parallel, execute in
order, only execute when all have preloaded.

[Use-case V:] As U, but don't need to wait for all before executing. Stop
executing if any script fails to load.

[Use-case W:] As W, but break on execution errors

[Use-case X:] Loading non-js dependencies
Solution: Use XHR + preload for prescanner

[Use-case Y:] Some libraries may need async initialization.
Solution: These libs should provide a ready promise.

[Use-case Z:] Wait on existence of particular element before executing
Solution: Either put the <script> that handles script loading after the
element in question, or use mutation observers


On 12 March 2014 14:27, Jake Archibald <> wrote:

> On 12 March 2014 14:17, Domenic Denicola <>wrote:
>> var img = document.createElement("img");
>> var promise1 = img.loaded();
>> img.src =" foo.png";
>> var promise2 = img.loaded();
>> // (1) will promise1 be immediately fulfilled, since img has
>> "about:blank" or similar loaded already?
>> // (2) or will promise1 and promise2 fulfill at the same time, since
>> promise1 waits until a src appears?
>> // (3) or will promise1 be rejected with AbortError, similar to Jake's
>> previous case?
>> // (4) or it could be rejected with an "InvalidStateError" saying you
>> can't wait for the loading of a non-src'ed image.
>> Here (1), (3), and (4) seem to encourage a consistent model of "always
>> ask for loaded() promises after setting src, otherwise it won't work". It's
>> (2) that's problematic as if that's the case then asking for loaded()
>> promises before setting src sometimes works, but usually doesn't.
> This is a very good point, and I'd say (4).
> Lets say you didn't change the src:
> (1) Means the promise would reject with an EncodingError as it isn't a
> valid image format
> (2) Would remain unresolved
> (3) N/A
> (4) Reject with InvalidStateError
> The consistency makes me like (4) the most.

Reply via email to