On Thu, May 29, 2014 at 4:05 PM, Ian Hickson <[email protected]> wrote: > On Thu, 29 May 2014, John Barton wrote: > > On Thu, May 29, 2014 at 2:31 PM, Ian Hickson <[email protected]> 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. > > Ok. > > Deferring loads and pre-declaring dependencies to enable browsers to > bundle requests is part of what I would like to address. >
The important dependency analysis problem that only a browser can solve is the resources needed to paint the visible screen. For example, if the footer is not going to be visible, then we can delay loading the components that build the footer. While I know that such an analysis would be difficult, this is the missing feature that deferring, async etc are poor proxies for. We need a component model that supports load-by-visible order or some such. Deferring loads isn't a dependency problem in the ES6 sense, it should operate at the root level or on HTML Imports. Building a list of dependencies to then have the browser send that list back to the server to request the resources is extra work: we can just have the server send all of these files. The server knows the dependencies, the browser does not. This is an optimization problem and the optimal place to perform it is the server (or the build plus server). > > 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. > > Right. CSS has them inline too. For other kinds of resources there's no > way to declare them at all right now. Ideally I'd like to add something to > browsers (probably something closely related to, augmenting, or subsuming > the ES6 module loading infrastructure) that enables authors to > declaratively pre-declare the relationships. This would also help with the > problem of how to bundle requests for modules and CSS. > Rather than bundling requests we can request bundles. The server already knows the dependency relationship because it has all the files. jjb
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
