ES6 modules (sorry...)

[Guy Bedford]

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 <caridy at gmail.com> 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 mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140616/43b9ed99/attachment.html>