Modules and dependencies known before the load
ian at hixie.ch
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
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the es-discuss