Integrating the Webs' dependency systems
johnjbarton at google.com
Tue May 27 17:26:04 PDT 2014
On Tue, May 27, 2014 at 4:51 PM, Ian Hickson <ian at hixie.ch> 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
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
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss