Integrating the Webs' dependency systems

John Barton johnjbarton at google.com
Thu May 29 17:27:29 PDT 2014


On Thu, May 29, 2014 at 4:05 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Thu, 29 May 2014, John Barton wrote:
> > On Thu, May 29, 2014 at 2:31 PM, Ian Hickson <ian at 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.
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140529/48a238ce/attachment.html>


More information about the es-discuss mailing list