Re: [whatwg] Preloading and deferred loading of scripts and other resources

[[stuck in the mod queue.. attempt #5, apologies for dupes if you get them]]

Ian, thanks for writing this up.

The first thing that strikes me about this entire topic is its scope, and
I'm wondering if we should take a step back and (a) extract some lower
level primitives, (b) leave the rest to libraries and web developers to
experiment with, and (c) if (b) leads to some good patterns, then codify
them at a later date... Instead of trying to tackle all of this at once.

In particular, it seems like we might be coupling two topics:
(1) a flexible declarative mechanism to fetch arbitrary resources
(2) some set of mechanisms to express dependencies, execution order, etc.

If we do our job right with (1), I think (2) can (should?) be deferred to
developers and library writers.

Specifically, for (1):
- We need a way to initiate arbitrary downloads that doc + preload parsers
will understand and can process
- We need a way to communicate type, prioritization, MQ, and other custom
fetch information for each download
- We need a way to listen on download progress of these resources to build
custom processing logic
- By default there is no UA processing on the response, this mechanism
simply fetches bytes

This is the direction I was proposing earlier [1] with rel=preload -- see
[2], for a concrete example.

I really like your proposal for "as="... Concretely it could look something
like this:

<link rel="preload"
        href="/some/asset.css"
        as="stylesheet"    (used to initialize default priority, headers,
etc)
        load-settings="{}"  (JSON payload with custom headers, priority
[2], etc)
        media= "..."          (relevant media queries..)
        probability=""        ([0.0-1.0] used for speculative fetches [3])
>

The combination of all of the above allows me to fetch any content-type,
specify custom priorities and headers (or use a default set via 'as'),
apply MQ's, etc. Given all that, assuming I can extract a Promise/Fetch
object (or some such) out of it, I can then track the download progress and
apply any arbitrary logic for how and when it should be processed. For
example:

- I can execute a script immediately by waiting for the download to finish
and inject the script tag referencing same URL
- I can setup a callback that waits for any other arbitrary resource to
finish before I execute it...
- I can defer execution until a particular action occurs.
- I can prefetch arbitrary resources for later use
- ...

(note: the script example is completely arbitrary.. the entire point is
that this mechanism is independent of content-type)

In other words, it seems like you could build most (all?) of the doc'ed use
cases in client-land... I can implement needs, loadPolicty, addDependency
on my own. Which, in my books, is a much better outcome anyway because it
will allow more and much more rapid experimentation.

---

[1]
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2014-August/297383.html
[2]
https://docs.google.com/presentation/d/1Q-7keKXwP2UeZ2zTN9Ue2ASIdIZPqxnEvnDsPSLTwcQ/present#slide=id.g377330538_0345
[3]
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2014-August/297437.html
[4]
https://docs.google.com/presentation/d/1Q-7keKXwP2UeZ2zTN9Ue2ASIdIZPqxnEvnDsPSLTwcQ/present#slide=id.g120f70e9a_025

Received on Tuesday, 26 August 2014 15:46:26 UTC