Here is a working example of dependency tree caching with an ES6 loader extension - https://github.com/systemjs/systemjs/blob/master/lib/extension-depCache.js
This allows dependencies to be declared upfront, and then all deep dependencies are requested in parallel with the module request (removing the round trip latency problem). It works out quite elegantly within the loader hooks, and avoids problems with duplication etc as long as the current spec bug relating to load promise caching is addressed. In a similar way bundling scenarios can also be fully catered for through the hooks. Surely these sorts of scenarios should be the job of Link subresource hinting, and HTTP/2 push in future? If so having them solved through the hooks and not the spec itself makes a lot of sense. On 29 May 2014 18:38, John Barton <johnjbar...@google.com> wrote: > > > > On Thu, May 29, 2014 at 2:31 PM, Ian Hickson <i...@hixie.ch> wrote: > >> On Thu, 29 May 2014, Juan Ignacio Dopazo wrote: >> > > >> > > - some people want to predeclare a bunch of scripts and their >> > > dependencies, without actually downloading any of them ahead of >> time, >> > > and then later, when they're needed, have the entire tree downloaded >> > > all at once. >> > >> > At the moment we're doing this by running static analysis tools on the >> > ES6 modules and using the information from the dependency tree to know >> > how to download all of them at once. >> >> Right, it's relatively common for people to do this. Not just for scripts, >> indeed, but also for style sheets and other resources. > > > FWIW, we call this "bundling". I mentioned it earlier as a problem that > ES6 has not addressed. It is specific to browser needs. > > >> Ideally the browser >> would take care of this logic for the author. This becomes especially >> difficult when there's multiple leaves in the dependency tree, with a lot >> of shared roots, and you just want the files you need (and in particular, >> you don't want to wait for the files to have been downloaded to discover >> what the next level of dependencies is, since that would add one >> round-trip time per dependency level). >> > > At least for ES this has to be done in the server: the dependencies are > declared in the source. > > ... > >> > > I'm having difficulty understanding the spec for the instantiate >> hook. >> > > Does it get called before the fetch hook? Is there some way to >> > > dynamically add dependencies later? >> > >> > The lifecycle of a module request is normalize -> locate -> fetch -> >> > translate -> instantiate. Instantiate doesn't actually execute anything >> > until all of the dependencies have gone through the same 5 steps. >> >> Aha, ok. >> >> Is there a way to add dependencies before the "fetch" hook is called? >> > > At least the draft of the Loader spec we followed did not allow a "loader > hook" to add dependencies. Honestly the newer draft has so much detail I > cannot be sure what the API is, but there were a few calls that amount to > parsing the file and extracting the dependencies. If these call were API, > then tools could add dependencies at the right time in the pipeline. I've > advocated for this simply because it makes the system easier to understand. > > >> >> When is the "fetch" hook called in the current ES6 logic? As soon as >> "locate" provides a URL? >> > > Yes, unless the request already has full URL and locate() is not called. > > >> >> -- >> Ian Hickson U+1047E )\._.,--....,'``. fL >> http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. >> Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' >> > > > _______________________________________________ > 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
