On Thu, Aug 21, 2014 at 1:55 PM, Ian Hickson <i...@hixie.ch> wrote: > On Thu, 21 Aug 2014, John Barton wrote: > ... more misunderstanding about bundles skipped... >
Let's give upon discussing bundles and pursue your dependency list scheme. > > > > > I don't think it should be particularly complex. It only requires some > > > minor changes. One is that we need to be able to declare dependencies > > > ahead of the "instantiate" hook. > > > > By the way I recently discovered that the deplist returned by the > > instantiate hook does not enter the dependency graph analysis. These > > aren't dependencies in a list rather a list of things needed to be > > loaded. > > I'm not sure what you mean here. The list returned from "instantiate" is > treated the exact same way as the list auto-discovered from "import" > statements when "instantiate" returns undefined: it's passed to > ProcessLoadDependencies(), which calls RequestLoad() and > AddDependencyLoad(), which, if necessary, updates [[Dependencies]]. > I'll defer to Guy Bedford's expertise: https://github.com/ModuleLoader/es6-module-loader/pull/204 > > That's all I'm talking about. I want to be able to update [[Dependencies]] > earlier than "instantiate", and I want to be able to mutate > [[Dependencies]] to remove nodes that are no longer dependencies before > the load is complete. > > > > > Another (a subset, really) is that we need to be able to declare > > > dependencies for ES6 modules as well as letting the ES6 infrastructure > > > discover them automatically. > > > > In theory this should be straight-forward. In practice, well good luck. > > Good luck with what? > The JS module space has had so many rounds of discussions that many participants are no longer willing to consider alternatives to their current point of view. > > > > > 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 anyone here is going to shy away from technically difficult > problems, it's kind of our bailiwick. :-) > Sometimes it is better to have a simpler and less powerful tool which can be well understood than a tool with many difficult-to-master features. Mutating dependencies opens the door to many new kinds of bugs, not only in the implementation of the Loader but, more important, in the use of the Loader by developers. > > The idea is, in fact, to move as many of the technically difficult > problems from things authors have to keep reinventing to things that > browsers just support natively. > > > > > > I guess you're proposing the send the dependency graph to the > > > > browser, then when a new root is needed, the stored graph is > > > > compared with the currently-loaded modules. The additional modules > > > > needed are then requested as a group. Up to this point we can just > > > > use build tools and browsers. > > > > > > Actually, modulo the changes described above, the ES6 loader already > > > does all this. > > > > Huh? How do you plan to parse the modules to obtain dependencies without > > sending them to the browser? > > You send them to the browser, just not in the module itself. > Where do you get them from? For ES6 it has to be from a build tool or from the server because no one is going to type these in twice. Such a build tool is just not very difficult and it can be built in to dev servers so it has no impact on developers work flow. > > > > > It just doesn't quite handle it at the level of pre-emptive > > > declaration of dependencies. But suppose you had two modules A, B, and > > > C. A and B depend on C. With ES6 today, when A is loaded, it loads C. > > > If late you load B, B doesn't reload C; it just links into it. So this > > > is all already supported. All that's needed is a way to tell the ES6 > > > system to get C before it has even received A. > > > > 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? > > Not sending C over the network at all wouldn't work, since it would mean A > doesn't have its dependencies available. I don't follow. > > The idea is that authors be able to predeclare (relevant parts of) the > dependency tree such that when a node in that tree is needed, e.g. A in > the example above, all the relevant nodes can be fetched in parallel, e.g. > A and C in the example above, rather than in a serialised manner, e.g. > first fetching A, then parsing it, then fetching C. > Authors have already predeclared the dependency relationships. Now you want them to re-declare them. Try it and let me know how many devs you convince. > > One way to do this would be to predeclare the modules, as in: > > <script type=module src=a.js id=a needs=c load-policy=when-needed> > </script> > <script type=module src=b.js id=b needs=c load-policy=when-needed> > </script> > <script type=module src=c.js id=c load-policy=when-needed> > </script> > Go back to G+ and ask them if they plan to type thousands of such lines into their .html files. Talk about a scaling problem! jjb
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
