The latency problem caused by tree depth can also be solved with a Link prefetch header (when Chrome re-enables this) from a server trace or a simple loader extension that contains a traced dependency cache. Injecting a trace tree is a much simpler and better alternative to bundling as we get the cache benefits Caridy mentioned.
Bundling is only needed in the short to medium-term. I agree native bundling shouldn't be specified to solve a problem that won't exist in due course. On 16 June 2014 16:49, caridy <[email protected]> wrote: > > I thought SPDY was, to quote wikipedia, about: "reducing web page load >> latency and improving web security" >> > How does SPDY help when the issue is lots of small requests ping >> ponging back and forth between client and server? >> >> SPDY multiplexes the requests across the same connection, which is >> essentially a runtime bundling process at the browser level without the >> hazards of doing it manually, and getting the benefit of the granular >> caching at the browser level. >> > > Just so I understand, if the dependency tree a depth of 20 and say 300 > modules how many round trips from client to server will you need using > SPDY? The competition (ES5 prebuilt) uses one. > > > One roundtrip, one cookie is sent, and 300 entries are added into cache. > Imagine making a change in one of those 300 modules, today, with bundling, > the ES5 prebuilt entry in cache gets stale, and you now have to loaded the > whole thing, while using SPDY, only one entry gets stale, so, next time the > user visits the app/page, only that piece will have to be loaded over the > wire, the rest is just going to rely on the browser's cache. This is a > killer feature, specially if you're doing continues deployment. > > >> > (Do we want to wait for SPDY in every browser before we use ES6 >> modules?) >> >> All major browsers (including safari) support SPDY today. But the point >> is, we should not consider "bundling" as a prime use-case for modules, >> because it is not going to be important at all. > > > > >> If people want to do bundling, they will have plenty of options to do so, >> even with the current module specs. >> > > Could you enumerate these? I thought that there was no option, which is > why we are asking. > > > We have been working on transpilers to transform ES6 modules into dynamic > modules that can in fact be used today, but also tomorrow, these dynamic > modules (which are covered in the specs today under the loader section) can > be bundle up. In other words, you can use the same tools that you use > today, e.g.: browserify, and they will work just fine. > > /caridy > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
