Bundling vs sending serialized dependency graph
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>
> >> 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
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
> > 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...
More information about the es-discuss