Bundling vs sending serialized dependency graph

John Barton johnjbarton at google.com
Thu Aug 21 08:54:05 PDT 2014

On Thu, Aug 21, 2014 at 8:37 AM, C. Scott Ananian <ecmascript at cscott.net>

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

Where? The Load Request records imply a dependency graph. Are these
maintained though out the life of the page? I don't see any existing reason
to expect these are maintained.

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

You deleted the context of my comment. I asserted that a build tool was
needed. Ian claimed the Loader could do it. Now you are claiming I'm wrong
because a build tool is used.

> This doesn't seem so crazy to me.

That's because you left out the crazy part ;-)

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

I agree that the part of Ian's story about sending over the deps list is
beginning to sound very attractive. In fact I think it is a stronger story
than the current spec altogether.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140821/0d20f5d2/attachment.html>

More information about the es-discuss mailing list