[whatwg] Script preloading

[Jake Archibald]

On 9 July 2013 21:41, Kyle Simpson <getify at gmail.com> wrote:

> http://wiki.whatwg.org/wiki/Script_Execution_Control
>
> My proposal was to standardize what IE4-10 did, which is to start loading
> a script even if it's not in the DOM, but not execute it until it's in the
> DOM. Then, you monitor an event to know if one or more scripts have
> finished this "preloading", and then you can decide if and when and in what
> order to add the corresponding <script> elements to the DOM to allow
> "execution" to proceed.
>

The IE4-10 technique is invisible to pre-parsers, if we're chasing
performance here it's not good enough.


> Setting aside IE's non-standard event mechanism, Nicholas' proposal was
> also perfectly sensible, and pretty simple. He suggested the same mechanism
> for execution (adding a <script> to the DOM), but suggested a `preload`
> attribute on the element to prevent auto-execution, and a `onpreload` event
> to notify you of loading-complete.
>

Also invisible to preloaders.

You could make "preload" an attribute which does a non-blocking download
but not execution. This is visible to preloaders and falls back to standard
ordered blocking loading which is fine. Then you'd have a method to
trigger execution of the script later. This is Hixie's "whenneeded"
proposal.

However, "whenneeded" is more complex than "dependencies". Unless there's a
good use-case for deferred parsing that can't be handled by
link[rel=subresource] and similar, "dependencies" is the better option.

> 1. Add a "dependencies" attribute to <script> that can point to other
> >   scripts to indicate that execution of this script should be delayed
> >   until all other scripts that are (a) earlier in the tree order and (b)
> >   identified by this attribute have executed.
> >
> >     <script id="jquery" src="jquery.js" async></script>
> >     <script id="shims" src="shims.js" async></script>
> >     <script dependencies="shims jquery" src="myscript.js" async></script>
>
> …content-management-systems (through plugins) load different items into a
> page independently of other plugins. Those plugins have no knowledge of the
> complete content/markup-structure of the page…
>

If "dependencies" took a CSS selector it could be:

<script dependencies=".cms-core" src="cmd-plugin.js"></script>

Now the number of scripts with class "cms-core" can change between versions
of the CMS but the plugin still waits for them all. No ID generation
needed. Does this fix the issue for you?


> Moreover, this ignores some use-cases for "script preloading" which are
> basically speculative preloading. I may want to load several plugins, but
> not execute any of them, and then only use one of them depending on what
> the user does.
>

This can be better achieved with things like link[rel=subresource] which
work for more than just scripts. When the script is required, it can be
added to the page with js, using something like LabJS or the "dependencies"
attribute to control execution order if necessary.


> So, the real need here is NOT just to chain a set of scripts together, but
> to put the author in control of pausing a script between load and execute,
> and then they get to decide when/if they unpause a script.
>

Given the above, is there a usecase that isn't catered for by
"dependencies" and existing preloading features?


> > 2. Add an "whenneeded" boolean content attribute…
>
> It doesn't solve the "I need an event to know when load is finished". If
> I'm waiting for a bunch of stuff to load before asking any of them to
> execute (in the order I want), I need a way to know that each of them are
> in fact fully loaded.
>

Sorry to keep being Mr Use-case, but what do you need to do that isn't
catered for? You can call markNeeded() when you want the script executed &
both a promise and the script's "load" event will tell you when it's done.
Why would you need to know when it's downloaded but not executed?


> Secondly, it seems like a bit more complex version of Nicholas' proposal,
> with just different names. Not sure why the complecting of API with
> (mostly) his same semantics.
>

To me, it seems like a simplification of Nicholas' proposal, but still more
complicated than "dependencies" without good reason. Also, it works with
preparsers. Can you provide a comparison that shows another suggestion to
be simpler than both of Hixie's proposals and match/beat it's performance?