Modules and dependencies known before the load

Ian Hickson ian at
Fri Aug 15 09:43:56 PDT 2014

On Thu, 14 Aug 2014, John Barton wrote:
> But since the only way the client can know that it needs a.js and 
> jquery.js is if the server tells it [...]

There's at least four ways this can happen:

 - the server tells the browser that it needs file a.js when the server is 
   sending index.html, then tells the browser that it needs query.js when 
   it is sending a.js, and the server doesn't preemptively send anything.

 - the server sends the browser all three files at once, preemptively.

 - the server tells the browser that it needs file a.js when sending 
   index.html, then when a.js is requested, it preemptively sends 
   jquery.js at the same time as telling the browser that it'l need it.

 - the server tells the browser that it needs files a.js and jquery.js at 
   the same time as when it is sending index.html, and the server doesn't 
   preemptively send anything.

The first is too slow, since it requires one RTT per file. It's what we 
have now, and what ES6 modules describe in the absence of server support.

The second is too slow, because it implies sending resources that aren't 
needed, possibly using up bandwidth that could be used for other purposes. 
It's something that can be supported by packaging and other solutions 
already being developed, if people want it.

The second and third require server-side support beyond what many authors 
will be able to do. HTTP2 can provide this if people want it, I believe.

The fourth is what I'm looking at.

The fourth consists of the server having no built-in knowledge except 
what is in-band in the HTML file, namely, predeclared dependency trees.

> > The key is just that the client can request all the files it's going 
> > to need at one time, so that, even without server support, the client 
> > doesn't wait more than one total RTT.
> Wait, you claimed earlier that without server support it's extra round 
> trips. Now without server support it's no extra round trips.  Which one 
> ;-)

As specced in ES6, it's one extra round trip per depth in the dependency 
chart; with predeclared dependencies, which is what I would like the ES6 
module system to enable me to support in the HTML spec, it would be one 
RTT per branch of the dependency tree that is activated at once.

> If you meant "suppose we had magic file on the server which listed 
> dependencies and a Loader that read that file, then we can succeed by 
> building the magic file and don't need server code changes".

Well, the file wouldn't be magic. It'd just be a predeclared dependencies 
in the HTML file, something that authors have long asked for, at least on 
the WHATWG list.

> That's what "bundling" does: builds a magic file and ships all of the 
> required modules in dependency order to the server. It even skips the 
> step where the list it built and just sends the all the dependencies.
> Could we have better tools that allowed finer grained control over the 
> bundle size vs trips? Sure.

Ok, great. That's all I'm asking for. Actually I'm asking for less than 
that, I'm asking if the ES6 module system could be slightly adjusted so 
that this finer-grained control could be implemented on top of it without 
duplicating the dependency management (which is what you have to do now 
if you manually call LoadModule() on the dependencies early).

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

More information about the es-discuss mailing list