Integrating the Webs' dependency systems

Ian Hickson ian at hixie.ch
Wed May 28 15:26:29 PDT 2014


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?


> 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.

I agree that a bundling system would also be useful. It's not what I 
happen to be working on at the moment, however.


> > > > > 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.

Ah, I see.

My goal here is to define the System part so that that part is 
well-defined and, more specifically, so that other aspects of the Web 
platform that do similar things, such as HTML imports and various other 
new HTML features, can all be defined in terms of the same underlying 
mechanism. Hopefully having such a system be well defined and 
interoperable will enable the kinds of scripted extensions you mention.


> > > 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 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.


On Wed, 28 May 2014, Juan Ignacio Dopazo wrote:
>
> The W3C System would have to provide the following hooks in a way that 
> matches what the web platform is supposed to do:
>
> * normalize hook: take a module ID string (like from import 'some-id' 
> and normalize it to a unique ID through out the system
>
> * locate hook: based on the module ID, locate the asset to be fetched 
> somehow (find its URL)
>
> * fetch hook: make the necessary network request
>
> * translate hook: probably not something the web platform will care 
> about for now since its intended to translate other languages into 
> EcmaScript
>
> * instantiate hook: if the fetched source is an ES6 module, then 
> everything is covered. But if it's any other asset or a dynamic module 
> (read AMD or similar) the instantiate hook is in charge of creating the 
> necessary Module instance. For example, it would deal with things like 
> importing CSS files by returning an empty module.

Aha, thanks. Having this made looking up the hooks in the spec easier.

Are these to be provided by a host object that implements these hooks?

Is there an IDL block that describes the System object that the browser 
has to implement? That would make my job of speccing the default System 
object (assuming that's my job) significantly easier.

One thing I don't see in the hooks above is anything to do with actually 
processing dependencies. How would I (at the spec level) tell the ES6 
module system that it should not evaluate a particular module until some 
non-script resource, e.g. a style sheet, is available?

One thing about this is it seems very script-centric. It would be weird if 
every time there was a <link rel=stylesheet> in the document, we 
implicitly went through an ES6 module's instantiate hook just to fire up 
the style sheet. Is there some way we can make this more generic?

For example, would it make sense to have the logic that handles Load 
Records be moved to another spec?

Alternatively, if ES6 is the spec that's going to manage the load records 
for all the loads for a Web page, is there some way we can augment this 
mechanism to handle the features that we need for other parts of the Web 
platform, like lazy loading, deferring, and so on?

  
> Given all this and the previously mentioned <module> tag, <script 
> needs=""> probably doesn't make much sense, does it?

Well, not everything is going to use modules (e.g. nothing today does). 
Also, it's not only scripts that are the problem here. For example, having 
images depend on style sheets (with both loaded just when the image comes 
into view) is one of the use cases that people have brought up that would 
be good to support.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


More information about the es-discuss mailing list