Integrating the Webs' dependency systems
johnjbarton at google.com
Wed May 28 15:58:42 PDT 2014
On Wed, May 28, 2014 at 3:26 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Tue, 27 May 2014, John Barton wrote:
> > 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
> > <https://people.mozilla.org/~jorendorff/es6-draft.html> literally under
> > the term 'hooks'.
> I hate to be "that guy", but can you be more specific? I did a search for
> the term "hook" and there were 85 hits; "hooks" had 6 which mentioned
> various things but none of them seemed to be near a list of specific
> hooks, their interface, and their meaning. Is the list that Juan described
> (see below) the list you had in mind?
Yes. You can also look at Guy Bedford's implementation of System:
or Traceur's implementation of LoaderHooks:
(The traceur implementation includes compiler-ish hooks not relevant to
> > > > 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.
> Well, something in the HTML spec has to "invoke System.import()" and all
> that jazz, right? That's what I'm trying to make sure we spec here.
The document imported by HTML Import would depend on some ES6 modules and
it would contain some CSS and HTML. Knitting these together would require
some JS execution which would compute references to the CSS/HTML and pass
them to ES6 code for processing. That bit of glue code would probably live
in the Imported document. We can have examples but I don't see how to spec
it unless there are Import-specific functions for obtaining the references
to the content from the Import.
> > 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.
> Right, that's what I'm trying to do.
This would seem to require Web-specific extensions to System as I mentioned
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss