[whatwg] Script preloading

[Glenn Maynard]

On Tue, Aug 27, 2013 at 4:55 PM, Ian Hickson <ian at hixie.ch> wrote:

> IMHO, if you have to write a script to solve use cases like these, you
> haven't really solved the use cases. It seems that the opportunity we have
> here is to provide a feature or set of features that addresses these use
> cases directly, so that anyone can use them without much work.
>

This is especially true for a module loader, which will be used to deal
with interactions between scripts written by different parties.  If the
platform doesn't provide a standard, universal way to do this, then people
will keep rolling their own incompatible solutions.  That's bearable for
self-contained code used by a module, but it doesn't make sense for the
piece that handles the cross-vendor interactions.

Anyway, the idea of only providing basic building blocks and making people
roll their own solutions isn't the web's design philosophy at all, so I
don't think it's a valid objection.


>  <script whenneeded="jit"> is a special mode where instead of running once
>  the script's dependencies are met, it additionally waits until all the
>  scripts that depend on _it_ are ready to run. ("Just in time" exection.)
>  (The default is whenneeded=asap, "as soon as possible" exection.)
>

This mode seems to be specifically for this use case:

> [Use-case U:] I have a set of script "A.js", "B.js", and "C.js". B
> relies on A, and C relies on B. So they need to execute strictly in that
> order. [Now], imagine they progressively render different parts of a
> widget. [...] I only want to execute A, B and C once all 3 are preloaded
> and ready to go. It's [...] about minimizing delays between them, for
> performance PERCEPTION.

This one seems uncommon, and less like a dependency use case than the
others.  How often is this wanted?  Is it too inconvenient to just mark
them all @whenneeded, and say something like:

document.querySelector("#C").execute(function() {
    A.render();
    B.render();
    C.render();
});

That does require the modules render in a function, and not when the script
is first executed.  I don't know how much of a burden that is for this
case.

Alternatively, if an event is fired when a script's dependencies have been
met, then you could mark all three scripts @whenneeded, and call
(#C).execute() once C's dependencies have been met.

Maybe the "jit" feature isn't a big deal, but it seems like a bit of an
oddball for a narrow use case.

 You can manually increase or decrease a dependency count on <script>
>  elements by calling incDependencies() and decDependencies().
>

Will a @defer dependency effectively defer all scripts that depend on it?

incDependencies() and decDependencies() may be hard to debug, since if
somebody messes up the counter, it's hard to tell whose fault it is.  A
named interface could help with this: script.addDependency("thing"); /*
script.dependencies is now ["thing"] */ script.removeDependency("thing");


On Thu, Aug 29, 2013 at 10:37 AM, Nicholas Zakas <
standards at nczconsulting.com> wrote:

> The question of dependency management is, in my mind, a separate issue and
> one that doesn't belong in this layer of the web platform. HTML isn't the
> right spot for a dependency tree to be defined for scripts (or anything
> else). To me, that is a problem to be solved within the ECMAScript world
> much the way CSS has @import available from within CSS code.
>

This would serialize script loading, because you wouldn't know a script's
dependencies until you've actually fetched the script.  That would make
page loads very slow.

I think the use cases other than the initial one (preload/execute later)
> are best relegated to script loaders


I disagree.  See above.

(Please remember to trim quotes.)

-- 
Glenn Maynard