ES6 Loader proposed changes
ian at hixie.ch
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
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the es-discuss