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
