Are ES6 modules in browsers going to get loaded level-by-level?

James Burke jrburke at gmail.com
Fri Apr 24 21:25:15 UTC 2015


On Fri, Apr 24, 2015 at 11:39 AM, Brendan Eich <brendan at mozilla.org> wrote:

> Not "bundling" in full; your previous post talked about HTTP2 but mixed
> dependency handling and bundling. You seemed not to advert to the problem
> of one big bundle being updated just to update one small member-of-bundle.
> One can be skeptical of HTTP2 but the promise is there to beat bundling.
>
> So in a future where ES6 or above is baseline for web developers, and
> HTTP2 is old hat, there won't be the full bundling and module body
> desugaring you seem to be insisting we must have in perpetuity. (Yes, there
> will be dependency graphs expressed concisely -- that's not bundling.)
> Right?


There are some nice things with HTTP2 and being able to update a smaller
set of files vs needing to change a bundle.

I am mostly concerned about startup performance primarily on mobile
devices, and in the offline cases where HTTP2 is not part of the equation,
at least not after first request. For the Firefox OS Gaia apps, they are
currently zip files installed on the device. The same local disk profile
exists with service worker-backed apps that work offline.

In the Firefox OS case, loading the bundle of modules performs better than
not bundling, because multiple reads to local disk was slower than the one
read to a bundled JS file. I expect this to be true in the future
regardless of ES6 baseline or the existence of HTTP2.

A bundle of modules that have already been traced, usually ordered by least
dependencies first, most dependencies last in one linearized fetch vs. in
the unbundled case, the dependency tree needs to be discovered and then
fetched as the modules are parsed.

It is hard to see the second one winning enough to discard wanting to
bundle modules. Even if the bundle alternative is some sort of zip format
that requires the whole thing to be available in memory. There is still the
read, parse, back-and-forth traffic to the memory area, converting that to
file responses. With service workers in play, it just adds to the delay.

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150424/02de7bf6/attachment.html>


More information about the es-discuss mailing list