ES6 modules (sorry...)

John Barton johnjbarton at google.com
Tue Jun 17 07:18:51 PDT 2014


I guess there is no technical argument that will convince you. Thanks for
at least having the discussion, more than we got before.

jjb


On Mon, Jun 16, 2014 at 9:02 PM, caridy <caridy at gmail.com> wrote:

> John, there are a couple of solutions at hand that you can apply:
>
> 1. loader provides the right hooks for you to hint at loader what are the
> modules you need to need to load. which is literally 10 lines of code for
> an extension of the loader:
> https://github.com/systemjs/systemjs/blob/master/lib/extension-depCache.js
> 2. partial bundling, which Guy Bedford explained in details
>
> You really don't need bundling for the new modules and the new loader.
>
> /caridy
>
>
> On Jun 16, 2014, at 8:19 PM, John Lenz <concavelenz at gmail.com> wrote:
>
> You don't really want 300/3000/30000 modules where you have to "load",
> "parse", then "request (dependencies)".  You really need your dependencies,
> pre-ordered and pre-loaded (that is bundled) if you want your "empty cache"
> clients to get a good experience.  SPYD is only one piece of a puzzle it
> isn't a silver bullet for solving module loading. If you want both to have
> an ideal experience you want bundles of modules and delta compression of
> your changes.  Unfortunately, there isn't a good delta compression solution
> yet but I have hopes that SDCH might be made more general and standard.
>
>
> On Mon, Jun 16, 2014 at 4:54 PM, John Barton <johnjbarton at google.com>
> wrote:
>
>>
>>
>>
>> On Mon, Jun 16, 2014 at 4:49 PM, 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.
>>>
>>
>> I agree this does sound great, I just don't see how the browser can know
>> which 300 entries to request until it parses the first entry. If on the
>> other hand you mean the server parses the modules, then it sounds
>> equivalent to bundling.
>>
>>
>>>
>>>
>>>> > (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.
>>>
>>
>> Ok, you must mean "TC39 don't have any options, you're on your own".
>>
>>
>>>
>>> /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/20140617/1e45574f/attachment.html>


More information about the es-discuss mailing list