ES6 Loader proposed changes

Ian Hickson ian at
Thu Aug 28 10:10:45 PDT 2014

Here are the changes that would be needed to make the ES6 loader 
infrastructure underpin the Web platform's loader infrastructure 
(basically, placing the ES6 loader the management layer between the Web 
platform APIs on top, and Service Workers underneath).

The ES6 module loader mechanism is very explicitly and specifically 
specified. It provides hooks that the UA can plug into, e.g. to actually 
dispatch loads, and it tracks the load state of each resource it is 
informed about, including what other resources that resource depends upon. 
If we can reuse this for the rest of the Web platform, it gives authors a 
really uniform API for all loading operations.

* Some document types are incrementally parsed, meaning that their 
dependencies are discovered before the "fetch" hook has finished. For 
these, it would be helpful if the dependencies could be reported to the 
ES6 machinery before the "fetch" hook finishes. (Right now, 
[[Dependencies]] is initialised as a response to the "instantiate" hook, 
at the end of the module load.)

* Ideally, it would be possible to provide the dependencies even earlier, 
e.g. at LoadModule() time, before the "normalize" hook, for the case where 
a custom module loader has a JSON file describing the dependency tree, or 
if, in future, HTML grows dependency information (the latter is likely).

* It is possible to mutate the DOM, including the URL of resources that a 
document depends on. For example, you can have an <img src="foo.png"> 
element, and dynamically change that attribute to have the value 
"bar.jpeg" instead. To manage this, the [[Dependencies]] list needs to be 

* Some loads have metadata other than dependencies, too. For example, 
anything loaded in CSS via the @import rule will always be parsed as CSS, 
even if it has already been referenced as an HTML file or ES6 module or 
PNG image elsewhere before: the load has the metadata "treat as CSS and 
don't dedupe". Similarly, <link rel=stylesheet> rules can have media 
queries attached to them. It would therefore be helpful if, rather than 
just a name, you could pass LoadModule() some metadata that would be 
passed along to all the hooks.

With the above changes, I think we could make ES6 modules underpin the 
entire Web dependency management system without needing to invent and 
expose yet another API, and without needing to redundantly manage the 
dependency tree. If we reuse the ES6 module loader to manage all HTML 
document resources, it would also trivially allow custom module loaders to 
allow ES6 modules to refer to other resource types without those module 
loaders needing to redundantly reimplement parts of the browser 
infrastructure (e.g. they could just hook into existing CSS style sheet 
loads rather than having to do separately load style sheets mentioned in 
ES6 modules).

Ian Hickson               U+1047E                )\._.,--....,'``.    fL       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

More information about the es-discuss mailing list