Integrating the Webs' dependency systems

Ian Hickson ian at
Tue May 27 16:51:27 PDT 2014

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?

> > > 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"?

> > However, it's very much my goal to be able to address use cases that 
> > don't involve any script at all (and that work even when the browser 
> > has scripting disabled), for example, I'd like whatever solution we 
> > develop here to be able to handle prioritising the loading and 
> > applying of different style sheets and images, e.g. so that images 
> > that are not currently rendered aren't downloaded yet, even though 
> > they are mentioned later in the page. One could imagine having markup 
> > like:
> >
> >    <link href="foo.css" rel=stylesheet load-policy=on-demand
> >          id="foo-styles">
> >    ...
> >    <img src="foo.png" alt="..." load-policy=on-demand
> >         depends-on="foo-styles">
> >
> > ...where an <img> element is defined as being needed when it's 
> > rendered, and where the browser would therefore only fetch the image 
> > and its stylesheet when the image is scrolled into view.
> >
> > This would need to work without any script involved at all, but should 
> > the author later add script with its own dependencies, we would want 
> > all the script dependency stuff to use the same underlying system so 
> > that if the script needs foo-styles or the foo.png image, it would all 
> > work as one coherent whole.
> I think that developers with sufficient background to master load 
> policies and dependency graphs will also be able to master a small 
> script to achieve a similar result.

That's quite possible. However, scripting is sometimes disabled. The idea 
is that this mechanism would keep functioning even in such an environment.

Also, note that many Web developers will use these facilities without 
mastering them first. It would be unfortunate, IMHO, if anyone who wanted 
to say "only load this image once it's in view" had to also paste in some 
boilerplate script that they didn't understand.

> On the other hand, experienced developers would like to avoid these 
> kinds of complex declarative solutions if possible, since they are 
> difficult to debug and understand.

Yes, whatever solution we provide here should definitely also provide an 
API that authors can hook into.

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

> Overall I think we should experiment with the tools we almost have 
> before we try to couple them together or develop another overlapping 
> alternative.

My goal isn't to define anything overlapping; my goal here is very much to 
avoid defining anything overlapping but for us to make sure that the one 
system we have actually addresses the needs of the three ongoing projects 
here - ES6 modules, HTML Imports, and the features being added to HTML to 
handle such things as not loading images until they're needed.

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

More information about the es-discuss mailing list