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 <car...@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 <concavel...@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 <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
