Modules and dependencies known before the load

John Barton johnjbarton at google.com
Fri Aug 15 10:00:08 PDT 2014


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 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. No one is going to write hundreds of lines of dependency
declaration already specified in their JS files.

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.

> ...
>
> > 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.


>
>
> > 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.

jjb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140815/53ef947f/attachment.html>


More information about the es-discuss mailing list