Bundling vs sending serialized dependency graph

Russell Leggett russell.leggett at gmail.com
Thu Aug 21 10:38:25 PDT 2014

Not sure if my real world use case would be super helpful here, but just in
case, here it is. The app I work on is a very large single page app - over
150,000 lines of JS across more than 2000 files. Uncompressed, unminified,
and concatenated together, it weighs in at close to 10MB. We've been using
an in-house module solution (written before most modern tools), and it does
smart bundling using a dependency graph. We use import statements (in
comments) that are read using a build tool which builds the graph. The full
graph is broken into a hierarchy of code bundles that rely on load order
expectations. The hierarchy can go many levels deep if needed. Common
dependencies are moved up to the closest shared ancestor bundle, so there
is no code in multiple code bundles.

Right now, this solution works pretty well for us, but is certainly not
ideal. One nice thing is that there is a relatively small number (~40) of
independent bundles and they can all be created upfront and served from a
CDN with far future expiration. The downside is that there are definitely
common dependencies that are bundled into ancestors higher up than they
ideally should be.

With the current spec of modules and loaders, there is no way that we could
switch and rely on the behavior of ES6 modules for the reasons specified
here. If I have some new code loading point, I want all of the required
code to start loading at once. I can't wait for the dependency graph to be
figured out as files are getting loaded. The proposal for being able to
preload a dependency graph upfront would be tremendously useful for making
the switch. My preference would be some kind of json format through a
JavaScript API and not some weird script tag thing.

- Russ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140821/99b4f50d/attachment.html>

More information about the es-discuss mailing list