Bundling vs sending serialized dependency graph

C. Scott Ananian ecmascript at cscott.net
Thu Aug 21 08:37:32 PDT 2014

On Thu, Aug 21, 2014 at 11:00 AM, John Barton <johnjbarton at google.com> wrote:
>> Finally,
>> it would be ideal if we could also adjust those dependencies on the
>> fly, since if we're reflecting dependencies described in the mutable
>> DOM structure, it might be mutated.
> I think this one is technically difficult.

I don't think this is actually all that hard.  We have a dependency
graph, along with a list of things that are (a) required, (b) already
loaded, and (optionally) (c) in-flight.  We mutate the graph
arbitrarily, recompute the list of things that we need to load given
the new (a), compare that to (b) and (c), and then start new/cancel
old loads as necessary.  I don't think it's worthwhile to specify
incremental algorithms here, just specify the stop-the-world
computation over the complete graph.  Optimization left to the
implementation, if needed.

> Huh? How do you plan to parse the modules to obtain dependencies without
> sending them to the browser?
> You've really lost me now. I thought your goal was to avoid sending C over
> the network. Now you want to send it without even seeing A?

I think Ian has explained this multiple times already.  The HTML file
contains a declarative specification of all resource dependencies, via
attributes on script tags or some such.  This is either generated
manually or via some future authoring tool.

This doesn't seem so crazy to me.  And, since presumably we can
already deal with mutation of the dependency graph (see above), we can
always adjust those declarations to match "reality" after we parse the
module file (although probably only to add new edges, not remove any
declared dependencies).  Thus the base case with no explicit
declarations in the HTML matches the on-demand behavior given by
current ES6.

Ian, FWIW, I've been staying out of this thread mostly because you
seem to be on top of it -- and because frankly I've already been
exhausted by the module wars.  But IMO you're doing excellent work.

More information about the es-discuss mailing list