Are ES6 modules in browsers going to get loaded level-by-level?

John Barton johnjbarton at
Thu Mar 26 20:05:20 UTC 2015

An async load will call for a module that knows--synchronously--its
imports. The server can respond with the entire tree in one response.

The problem comes in avoiding duplicate transmission of modules shared by
multiple async loads. The client will need to signal the server about the
previously loaded modules.

If you search this list back to posts by Ian Hickson you can read about his
HTTP/2 based discussions.

Broadly this subject is considered by "professional" web developers as just
a moot point.  They consider dynamic loading with decisions made in the
client to be undesirable.  They do support what might be called "optional"
loading, where only part of the JS is loaded initially and more JS is
loaded later. But the dependency decisions are all baked into the server
and thus the tree of layers known only in the client does not arise.


On Thu, Mar 26, 2015 at 12:08 PM, Wizek <123.wizek at> wrote:

> *I've been redirected from here:
> . Not
> sure if this is a good place to ask this question. If not, I'm sorry for
> the noise. Could you then point me elsewhere perhaps?*
> I've just read this post here:
> Which claims that the module system will support both sync and async
> loading. Which I like. But it made me wonder if/how well async loading
> would work for deeper dependency trees. E.g. if I had a project with 20
> level deep dependency tree (at its deepest point) and my server would take
> on average 200ms to respond, then it would take about 4000ms minimum to
> execute any/all of my scripts, right? Or is there something I am missing?
> If I interpret the situation correctly, what is the conceptual response to
> this scenario? Try to limit the tree depth? Concat everything just like it
> happens often with ES5? Something else?
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list