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. `._.-(,_..'--(,_..'`-.;.' _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
