On Thu, Aug 21, 2014 at 8:37 AM, C. Scott Ananian <ecmascr...@cscott.net> wrote:
> On Thu, Aug 21, 2014 at 11:00 AM, John Barton <johnjbar...@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. jjb
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
