ES6 modules (sorry...)

Guy Bedford guybedford at
Mon Jun 16 16:49:20 PDT 2014

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

On 16 June 2014 16:49, caridy <caridy at> 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
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list