Ian Hickson (2014-08-28T17:10:45.000Z)
domenic at domenicdenicola.com (2014-08-29T02:53:33.232Z)
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 mutable. * 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).
domenic at domenicdenicola.com (2014-08-29T02:53:21.678Z)
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 mutable. * 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).