Bundling vs sending serialized dependency graph

Ian Hickson ian at hixie.ch
Mon Aug 25 09:27:10 PDT 2014


On Fri, 22 Aug 2014, Marius Gundersen wrote:
> >
> > 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>
> 
> All of these scripts would need to be empedded in every page

Only the ones that are needed. But actually it's not that bad. These 
dependencies can all be listed in an HTML import, which is then marked as 
heavily cachable. This ends up being just as cheap to pass to the server 
as a JSON file of the dependencies.


> Pre-fetching dependencies seems like it could most easily be implemented 
> using ServiceWorkers[1]. A simple build tool, given a set of modules, 
> can generate a JSON file with each module id (URI) and its dependencies 
> (list of URIs). This JSON file would contain the entire dependency 
> forrest from all roots to all leaves, and could be made available on the 
> webserver for the ServiceWorker to download.

That wouldn't let you do preparsing, which is a big part of the reason to 
want to prefetch resources.

(ServiceWorkers are an important part of the upcoming revolution in 
resource loading on the Web, but dependency handling is at a different 
level, namely, the ES6 loader level.)

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