Modules and dependencies known before the load

Ian Hickson ian at hixie.ch
Fri Aug 15 14:43:40 PDT 2014


On Fri, 15 Aug 2014, John Barton wrote:
> On Fri, Aug 15, 2014 at 9:43 AM, Ian Hickson <ian at hixie.ch> wrote:
> > 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 method is faster than your method. It results in the same 
> three file transfer in one less round trip.
>
> The second method does not imply sending any more or less resources than 
> any other method listed.

The second is too slow because there's lots of other files involved in 
practice, for example the default style sheet, the scripts that are needed 
straight away, the Web components that are needed straight away, all the 
default images, etc. The whole point of the discussion in this thread is 
that we're talking about files that are not needed straight away, and how 
to obtain them promptly once they are needed.


> > 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.
> 
> By humans writing markup? That's not happening, at least not for more 
> than trivial programs.

It turns out that on the Web, there are lots of "trivial" programs. When 
you have trillions of Web pages, even the smallest of fractions ends up 
being significant numbers of pages.


> No one is going to write hundreds of lines of dependency declaration 
> already specified in their JS files.

Maybe not hundreds, but maybe dozens. Also, not all these dependencies are 
written in their JS files. Also, it turns out that people will do lots of 
things to make their pages quicker, and it's a lot easier, in many cases, 
to adjust their markup than to adjust their server configuration.


> And if you allow a tool running on the server (eg a build) then its the 
> same as bundling with an extra unnecessary round trip.

The tool is likely to not be running on the server, but on the developent 
machine. It's unfortunate, and I don't really understand it, but it's a 
fact of life on the Web that many authors have only minimal control over 
their servers.


> > > 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.
> 
> You mean devs re-writing the same declarations they used in JS in HTML? 
> Do these authors write modular JS? I am very skeptical.

Currently, many of these developers don't write modular JS, no. However, 
my work here is intended to make it possible to use the ES6 module loading 
system even with legacy scripts, and to be able to declare dependencies 
for them too, so it's actually not a concern if it's not ES6 modules that 
they are writing.

Indeed it might not be script at all. Declaring dependencies just between 
style sheets, HTML imports, images, and other resources will similarly 
require a dependency system, and if we reuse ES6's rather than require 
all browsers to implement two or more dependency systems, then the 
requirements for those non-script cases end up applying to ES6 modules.


> > > 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).
> 
> You can specify dependencies in `instantiate()` returns.

That is not "before the load"; q.v. the subject line of this e-mail.

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


More information about the es-discuss mailing list