Integrating the Webs' dependency systems

Ian Hickson ian at
Thu May 29 12:33:49 PDT 2014

On Wed, 28 May 2014, Matthew Robb wrote:
> Perhaps it's too cumbersome to use the System loader to specify the 
> business logic for the browsers dependency loading/registry etc. Maybe a 
> low-level browser spec needs to exist that a light System object could 
> eventually defer to. This almost seems easier and more straight forward 
> (requiring less cross-spec coordination) to make progress on.

If this is something that a future ES spec would defer to, I'd be happy to 
work on that. Is that feasible?

On Wed, 28 May 2014, John Barton wrote:
> The Loader is very generic, it might be fun to see whether it could load 
> something other than JS.  The mechanism isn't really focused on load 
> records. Rather, the Loader is a dependency-tree walker with some 
> callbacks. Some callbacks are clearly defined and nicely generic 
> (normalize, locate, fetch, translate). Some callbacks are vague, 'parse 
> this and tell me what it imports'. Current these latter callbacks are 
> very JS-centric.  These would need work to eg parse CSS and return 
> imports.


> > How about marking a load as low-priority, is that something we can do 
> > with load records?
> No, because it makes no sense in a dependency-driven loader. The root of 
> a tree could be delayed (by the browser for example) but once we start 
> loading, priority does not matter.

The contexts in which I am interested about this kind of thing is:

 - some people want to predeclare a bunch of scripts and their 
   dependencies, without actually downloading any of them ahead of time, 
   and then later, when they're needed, have the entire tree downloaded 
   all at once. For example, you could have a lot of code to back video 
   playback widgets, but not want to download them (or the videos!) until 
   the user indicates a that they want to watch a video.

 - sometimes, even a file that is not downloaded immediately upon being 
   referenced by another file might still want to be precached, so that 
   when it _is_ needed, it's already locally available. These loads, 
   however, have to happen later than any loads for scripts or other 
   resources that are needed immediately.

 - some resources are needed to load the page, but should be deferred 
   until after the page is rendered. For example, Google+ tries to render 
   as fast as possible a static non-interactive version of itself, and 
   then after that is done, it downloads scripts and goes back and wires 
   up all the logic so that the page is interactive.

Many of these apply to modules, or interact with modules, which is why I'm 
interested in how we can adapt the ES6 spec to support prioritisation, 
predeclaring dependencies, dependencies on non-script resources, and so 

On Thu, 29 May 2014, Juan Ignacio Dopazo wrote:
> When you create a dynamic module in the instantiate hook you can specify 
> a list of dependencies like this:
> System.instantiate = function (loadRecord) {
>   return {
>     deps: ['some', 'list', 'of', 'dependencies'],
>     execute: function () {
>       // return a new Module instance
>     }
>   };
> };
> The Loader will know to wait for those dependencies.

I'm having difficulty understanding the spec for the instantiate hook. 
Does it get called before the fetch hook? Is there some way to dynamically 
add dependencies later?

On Thu, 29 May 2014, Mark Miller wrote:
> Compatibly extending the ES6 model *after* ES6 is certainly on the table.
> Regarding ES6 itself, not unless it's critical, and perhaps not even then,
> depending. That ship is sailing, airplane doors have closed, or whatever
> metaphor you like ;).

I just mean extending the ES model in general, I'm not trying to imply any 
particular version or whatever. (I forget that some specs are still using 
versioned snapshots, sorry. HTML is just on a rolling "living standard" 
model now, so new features can be added in one area at the same time as 
other areas are being implemented.)

> What's a "load record"?

Unless I misunderstood the spec, it's how the ES6 spec respresents a 
specific resource in the dependency tree.

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

More information about the es-discuss mailing list