Integrating the Webs' dependency systems

Ian Hickson ian at
Tue May 27 15:57:09 PDT 2014

On Tue, 27 May 2014, Matthew Robb wrote:
> @Ian, It seems like the first real question is, based on what will 
> eventually be in the ES6 Spec for the Loader API, what is the System 
> Loader as it pertains to the web/browser environment and is there 
> potentially a need for a specification of it here (or at least outside 
> of tc39).

I'm not sure I understand this question, but I'm happy for us to first 
answer this question, sure. :-)

How do we determine the answer to this question?

On Tue, 27 May 2014, John Barton wrote:
> I think the Loader nicely isolates these particular functions: I don't 
> see any urgency in standardizing them. However the delegation of the 
> specification of System leaves us in the weird place of having 
> everything except the actually external API spec-ed.  Web folks could 
> almost just say "Browsers shall have a window.System instance of 
> Loader". There is a missing part of the Loader spec essential for Web 
> and not very important for node: bundling for network transmission see 

I don't understand this paragraph. What does it mean for us to not 
standardise Loader's functions? Is System something that we are expecting 
some non-ES spec, e.g. Fetch or HTML, to define? 

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

On Tue, 27 May 2014, Kris Kowal wrote:
> Supposing that a page has both a service worker and a custom loader, I 
> would expect all requests for URL’s in the page (href, src, etc) to
> 1. pass through the page’s loader
> 2. pass through the browser's fetch mechanism
> 3. pass through the service worker
> 4. pass through the browser's fetch mechanism again
> 5. possibly arrive at the true service [...]

This sounds like feedback for the Fetch spec. Anne?

On Tue, 27 May 2014, Kevin Smith wrote:
> >
> > I don't think a URL is the right way to identify everything. Many 
> > things in the Web platform that you could legitimately want to depend 
> > on don't have a URL. For example, a promise, or an inline <script> 
> > block, or an HTML <video> element (the latter in particular would have 
> > several URLs, the whole point would be to depend on the element so 
> > that things only happen once that element has figured out which file 
> > it wants to play and is ready to do so).
> How would you identify such dependencies, within this system?  (The 
> identification must somehow allow de-duplication.)

Well for anything that is handed to the dependency system by calling some 
API and passing it an object, e.g. a promise or DOM Node, the object's 
very identity would presumably be sufficient. For declarative mechanisms 
that refer to elements by ID, the ID would presumably be a way to look up 
the element and then the element's inherent identity would suffice. In 
fact in the strawman I had proposed last year, the URL for a script wasn't 
actually used as the identity, what the proposal did was use the URL to 
look up the <script> element and then used the <script> element as the 
target of any deduping.

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

More information about the es-discuss mailing list