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

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 
mechanism.

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

   http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Aug/0177.html


> 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

   http://dev.w3.org/csswg/css-font-loading/

...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 
here.


> 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:

   http://esdiscuss.org/topic/es6-loader-proposed-changes

-- 
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