W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2014

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

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 9 Sep 2014 02:59:02 +0000 (UTC)
To: Ilya Grigorik <igrigorik@gmail.com>
Message-ID: <alpine.DEB.2.00.1409090245280.28228@ps20323.dreamhostps.com>
Cc: whatwg <whatwg@lists.whatwg.org>
On Mon, 8 Sep 2014, Ilya Grigorik wrote:
> Better or worse is not the point. I think the current proposal fails to 
> address the larger underlying problem.

If it did, then that would be "worse".

> The platform is missing a lower-level primitive (declarative and 
> imperative) that is able to explain resource loading with the same 
> expressive power as requests initiated by the browser itself.

That isn't a problem.

> XHR provides arbitrary resource loading, but it lacks the power to 
> express transport-layer options such as relative request priority

That is fixed by exposing Request initialisation flags on XHR.

> and dependencies,

That's fixed by using the proposal in this thread.

> and it also hides requests from the preload scanner, which is a 
> deal-break for performance.

That's why the proposal in this thread uses the existing import mechanisms 
to define how the dependencies.

> (2) We also need a declarative, content-type agnostic primitive to 
> express resource loads, such that the preload scanner is able to pickup 
> and processes these fetches on par with all other resources -- hence my 
> rel=preload suggestion.

I don't disagree that we need a way to declarative way to import 
non-browser-native resources (like some text file the script uses for 
storing game level data or something). But I don't think we need a 
redundant mechanism to import resource types that already have existing 
import mechanisms. That's not a "primitive", it's just a redundant 

I went into more detail on this very topic, considering a wide array of 
options, in the big e-mail I sent recently:


> We can augment img, script, and other elements, with load-settings and 
> other flags, but that still doesn't cover all the necessary cases. For 
> example, how do I fetch a font file


...which presumably would have loadSettings exposed.

> or an arbitrary JSON payload with app-data, etc?

XHR, or <link rel=preload>. I assume you're not expecting us to preparse 
the JSON file.

> Note that I'm looking for declarative syntax that allows me to set 
> arbitrary fetch priorities - e.g. upgrade my JSON payload to high 
> priority because I need it to render content on the screen. This is the 
> part that we *need* to solve.

rel=preload with the proposal on this thread handles this fine, as far as 
I can tell.

> Once we have the low-level declarative+imperative primitives for loading 
> resources, we can build up all other loading and dependency patterns in 
> app-space.

That people have to build them in app space is the bug I'm trying to fix 

> The loadpolicy/needs attributes are syntax sugar for select resource 
> types -- nice, but (IMO) not strictly necessary and not sufficient for 
> the more general case of content-types not covered by dedicated 
> elements.

needs="" is actually very little more than syntactic sugar over ES6 module 
loader primitives, assuming that we can get the ES6 module loader to be 
augmented to address the needs of non-ES resources:


Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 9 September 2014 02:59:27 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:23 UTC