On Tue, May 27, 2014 at 4:51 PM, Ian Hickson <[email protected]> wrote: > On Tue, 27 May 2014, John Barton wrote: > > > > > > Is System something that we are expecting some non-ES spec, e.g. Fetch > > > or HTML, to define? > > > > TC39 members have more than once explained that they expect some non-ES > > spec to define System. > > Ah, great. (Sorry if I sound dumb here, I'm very new to the whole module > thing. I tried reading the spec but it wasn't very clear to me.) > > Is there a description of what the non-ES spec should say? That is, what > is the interface that System exposes that needs to be "implemented" by > this non-ES spec? What are the spec hooks that this non-ES spec would need > to invoke? >
Each implementation of System has to supply the functions described in *https://people.mozilla.org/~jorendorff/es6-draft.html <https://people.mozilla.org/~jorendorff/es6-draft.html>* literally under the term 'hooks'. As I mentioned, the more important issue for browsers is bundling. Unless that is solved, the uptake of ES6 module loading will rely on non-standard mechanisms. Unlike the 'hooks', a bundling API is not defined by ES6 and it's not useful to node. It has superficial overlap with HTML Import, but the focus is on load performance rather than modularity. > > > > > > But to your original question about non-JS loading: you can extend > > > > the Loader class to add methods for CSS and HTML. These would be a > > > > cache in front of xhr for the most part, hence my suggestion that > > > > implementation (GitHub) is a good place to start. The next step, and > > > > one quite critical to practice, is integration with bundling. Here > > > > practical expertise is essential so again implementation would be a > > > > critical guide. There exist solutions in the pre-ES6 space to > > > > consult as well. > > > > > > This seems to imply that to do anything with this mechanism, someone > > > (the page author?) has to provide some script code. > > > > I believe that such an extension of the ES6 Loader has a chance to > > provide value to the community. I guess it won't solve all problems ;-) > > Would this be a replacement to the aforementioned "System"? > No, not replace. I meant 'extension' in the es6 sense: System would remain an instance of Loader, it just would have additional functions, functions only relevant to code dedicated to working on CSS/HTML. > HTML Imports offers a middle ground: while it is declarative it is also > > modular so the complexity can be divided and conquered. I don't think it > > requires script so it is an alternative starting point. > > My goal here is for us to make sure that ES6 modules and HTML Imports end > up specified using the same dependency mechanism. > I thought this would just work. HTML Imports will have <script> tags and those <script> tags will invoke System.import() and thus use the same dependency mechanism. The reverse however, where System could have a dynamic effect similar to static HTML Imports *and* use the same dependency mechanism for the CSS/HTML is not as far as I know possible short of adding Import tags to the document. This would be nice to have, but requires coordination with HTML Import. jjb
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
