Re: [whatwg] Script preloading

On 7/9/13, Ian Hickson <ian@hixie.ch> wrote:
>
> A topic that regularly comes up is script loading.
>
Yes, for years it has come up.

I jumped on the topic around 2009 here and on comp.lang.javascript to
add the idea about "chain of responsibility" to this solution.

The "chain of responsibility" pattern is not new, and some examples
include FilterChain and in Apache ANT. The concept seems to apply well
to this context.

> I sent an e-mail responding to related feedback last year, though it
> didn't get any replies to the script loading parts of it:
>
>
> http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0221.html
>
> It seems that people want something that:
>
>  - Lets them download scripts but not execute them until needed.
>  - Lets them have multiple interdependent scripts and have the browser
>    manage their ordering.
>  - Do all this without having to modify existing scripts.
>
> I must admit to not really understanding these requirements (script
> execution can be made more or less free if they are designed to just
> expose some functions, for example, and it's trivial to set up a script
> dependency mechanism for scripts to run each other in order, and there's
> no reason browsers can't parse scripts off the main thread, etc). But

That is a good point and it is a good approach.

> since everyone else seems to think these are issues, let's ignore that.
>
> The proposals I've seen so far for extending the spec's script preloading
> mechanisms fall into two categories:
>
>  - provide some more control over the mechanisms already there, e.g.
>    firing events at various times, adding attributes to make the script
>    loading algorithm work differently, or adding methods to trigger
>    particular parts of the algorithm under author control.
>
>  - provide a layer above the current algorithm that provides strong
>    semantics, but that doesn't have much impact on the loading algorithm
>    itself.
>
> I'm very hesitant to do the first of these, because the algorithm is _so_
> complicated that adding anything else to it is just going to result in
> bugs in browsers. There comes a point where an algorithm just becomes so
> hard to accurately test that it's a lost cause.
>
> The second seems more feasible, though.
>
> Would something like this, based on proposals from a variety of people in
> the past, work for your needs?
>
> 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>
>

Why limit "depends" to be used by only scripts to refer only to other scripts?

If you put <link depends=idref> on style then stylesheet evaluation
could be deferred, too.

I explained some cases about why this is desirable here:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-February/018435.html

The test cases I'd posted aren't live, but they did show some
confusion at the time regarding load order of resources. Surety of
misunderstanding seemed to be what caused the idea to be so
offhandedly dismissed.

>    This would download jquery.js, shims.js, and myscript.js ASAP, without
>    blocking anything else, and would then run jquery.js and shims.js ASAP,
>    in any order, and then once both have executed, it would execute
>    myscript.js.
>
> 2. Add an "whenneeded" boolean content attribute, a "markNeeded()" method,

A disabled/execute was mentioned here, before:
http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Apr/0158.html


>      document.getElementById('myscript').markNeeded();
>

I'd rather call execute() than tell Mark he's needed.

>    This would then cause the scripts to execute, first jquery.js and
>    shims.js (in any order), and then myscript.js. If any hadn't finished
>    downloading yet, it would first wait for that to finish.
>
>    (We could make markNeeded() return a promise, too.)
>
Or use a callback. Blocking on resource loading is bad.
-- 
Garrett
Twitter: @xkit
personx.tumblr.com

Received on Tuesday, 9 July 2013 21:38:43 UTC