On Thu, 29 May 2014, John Barton 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.

Ok.

Deferring loads and pre-declaring dependencies to enable browsers to 
bundle requests is part of what I would like to address.


> > 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.


> > > > 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.

The current spec seems to require that [[Dependencies]] be empty while 
[[Status]] is 'loading', so I guess we'd have to change that if we were to 
extend this. Can anyone explain what the implications of changing this 
would be?


> > 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.

I guess to make it possible to defer loads, we'd have to add some sort of 
logic in ProceedToLocate()?

-- 
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

Reply via email to