Bundling vs sending serialized dependency graph

Ian Hickson ian at hixie.ch
Thu Aug 21 16:21:50 PDT 2014


On Thu, 21 Aug 2014, John Barton wrote:
> >
> > 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

No need to defer to Guy. You can just look at the spec.

But FWIW, what Guy is saying there does not contradict what I said above, 
as far as I can tell.


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

It's not clear to me what to make of this.

Is feedback on the module system not welcome any more? The ES process is 
very opaque to me; it's not clear to me how to send feedback.


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

That is orthogonal to how difficult it is to provide those features. 
Indeed simpler features are usually more difficult to provide than the 
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.

I do not disagree.

The number of bugs that might be present if we have two separate 
dependency systems seems yet higher still, though. That's the alternative 
here, as far as I can tell, since HTML imports allow you to mutate 
dependencies already. What I'm trying to do is make HTML imports reuse the 
ES6 model as much as possible to avoid us having to have two dependency 
systems.


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

Same place you get the import statements you put in the script modules.


> For ES6 it has to be from a build tool or from the server because no one 
> is going to type these in twice.

A tool would certainly make things simpler, but I think you underestimate 
the motivations authors face when it comes to squeezing performance out of 
their Web pages.


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

Great! Such tools could trivially output the dependencies in a fashion 
interpretable by HTML processors.


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

I'm not trying to convince them, they're trying to convince me. I've 
received voluminous feedback over the years to the effect that they want 
to be able to do this.


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

Yup, this wouldn't work when there's thousands of modules. It does when 
it's just a few dozen, though, which is the more common case. Luckily for 
us, sites with the complexity of G+ are the extreme, and they are also 
the cases where the developers are most likely to have the resources to 
produce their own custom solutions.

Having said that, my understanding is that G+ does actually ship this 
information to the client currently, in a custom format. So it would not 
be that much of a stretch to imagine them putting it in an HTML import, 
say. Something that would allow them to have the dependency chain, without 
blocking the initial page load.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


More information about the es-discuss mailing list