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 <johnjbar...@google.com> wrote: > > > > On Mon, Jun 16, 2014 at 4:49 PM, caridy <car...@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@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
