On Fri, Apr 24, 2015 at 11:39 AM, Brendan Eich <bren...@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
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss