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

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Wizek
*I've been redirected from here: https://github.com/tc39/ecma262/issues/27#issuecomment-84474257 . 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?*

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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

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

HTH,
jjb

On Thu, Mar 26, 2015 at 12:08 PM, Wizek <[hidden email]> wrote:
*I've been redirected from here: https://github.com/tc39/ecma262/issues/27#issuecomment-84474257 . 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?*

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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Caridy Patino
In reply to this post by Wizek
The issue you're describing exists today, and it is the main reason why we do bundling (a la webpack, browserify, etc.).

ES6 modules are not introducing any new restriction here, it is just the way things work. HTTP2 is suppose to help in this regards, but only a little bit. In my experience, loading the modules is not even the biggest issue here, but executing 500 modules is, because it will require at least an order of magnitud more promises to be resolved, plus all the other normalization logic. This is where "folding" might help us. Assuming you have a huge tree of modules, we could analyze that tree and fold it into few modules that are key for the application to function, then fetching and executing those modules should not be a big deal, this is very similar to bundling as we know it today but without sacrificing module semantic, and loader advanced functionalities.

In any case, this should not prevent us from writing modules using ES6 import and export declarations today.

/caridy

On Mar 26, 2015, at 3:08 PM, Wizek <[hidden email]> wrote:

*I've been redirected from here: https://github.com/tc39/ecma262/issues/27#issuecomment-84474257 . 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?*

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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

medikoo
It'll be great to have some more insight on this.

To my knowledge when using ES6 modules as currently specified there's no way to introduce more than one module with one file.
So technically, the only way to use them natively in browsers, would be to serve them separately.
This raises the question. Is there any mean in sight, that will allow us to serve them as fast as we can serve hundreds of bundled and minimized CJS modules now?

Because if not, then landscape looks troubling. As it means that to have same performance, we will need to transpile ES6 modules for browser into something else, even though browsers may support them natively.
Reply | Threaded
Open this post in threaded view
|

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

Domenic Denicola
> Is there any mean in sight, that will allow us to serve
> them as fast as we can serve hundreds of bundled and minimized CJS
> modules now?

Yes. Any browser which implements the ES6 module loader (none of them right now) will also be a browser that implements HTTP/2 (all of them right now). HTTP/2 server push would allow you to respond to a single request for "entry.js" (e.g. from `<script type="module" src="entry.js"></script>`) with responses for all modules in the entire dependency graph, prioritized according to their level in the graph, all over a single TCP connection.

This is just the most naïve strategy I could think of with HTTP/2. There are more interesting ones too.

It's also important to note that bundling is an antipattern in the HTTP/2 world, as it prevents incremental cache updates by invalidating the entire bundle graph when you change a single file, and does not allow relative prioritization of individual files.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

John Barton


On Thu, Apr 16, 2015 at 12:18 PM, Domenic Denicola <[hidden email]> wrote:
> Is there any mean in sight, that will allow us to serve
> them as fast as we can serve hundreds of bundled and minimized CJS
> modules now?

Yes. Any browser which implements the ES6 module loader (none of them right now) will also be a browser that implements HTTP/2 (all of them right now). HTTP/2 server push would allow you to respond to a single request for "entry.js" (e.g. from `<script type="module" src="entry.js"></script>`) with responses for all modules in the entire dependency graph, prioritized according to their level in the graph, all over a single TCP connection.

This is just the most naïve strategy I could think of with HTTP/2. There are more interesting ones too.

It's also important to note that bundling is an antipattern in the HTTP/2 world, as it prevents incremental cache updates by invalidating the entire bundle graph when you change a single file, and does not allow relative prioritization of individual files.

But the push scenario in your first paragraph would not use the cache either.

As far as I can tell, only the client knows which modules it has loaded; only the server knows the dependency graph for modules-to-be-loaded. So: 
  one or the other has to send its information at the outset of a import request, or 
  the server needs to send the entire bundle, or 
  the loading has to be layer by layer.
HTTP/2 does seem to have the magic to avoid considering these issues in module loading.

jjb

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Domenic Denicola
From: John Barton [mailto:[hidden email]]

> But the push scenario in your first paragraph would not use the cache either.

Yeah, that's what I was alluding to with the "most naïve" comment.

>  one or the other has to send its information at the outset of a import request, or 

One way of doing this I came up with off the top of my head is to add some kind of "dependency graph version" or hash to the query string. I.e. <script type="module" src="entry.js?1234"></script>. The server can then assume that the client has in its cache version 1234 of the dependency graph, and can push the incremental updates since then (i.e. added or modified files). If parts of the cache were evicted, so that the versioning signal is not entirely accurate, then the penalty is not so bad, as you just fall back to the normal loading process for the evicted subset.

But I feel pretty silly speculating here as I'm not an expert on HTTP/2 techniques, and there are probably other methods that are better in various ways.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

John Barton


On Thu, Apr 16, 2015 at 1:22 PM, Domenic Denicola <[hidden email]> wrote:
From: John Barton [mailto:[hidden email]]

> But the push scenario in your first paragraph would not use the cache either.

Yeah, that's what I was alluding to with the "most naïve" comment.

>  one or the other has to send its information at the outset of a import request, or 

One way of doing this I came up with off the top of my head is to add some kind of "dependency graph version" or hash to the query string. I.e. <script type="module" src="entry.js?1234"></script>. The server can then assume that the client has in its cache version 1234 of the dependency graph, and can push the incremental updates since then (i.e. added or modified files). If parts of the cache were evicted, so that the versioning signal is not entirely accurate, then the penalty is not so bad, as you just fall back to the normal loading process for the evicted subset.

But I feel pretty silly speculating here as I'm not an expert on HTTP/2 techniques, and there are probably other methods that are better in various ways.

Perhaps, but I feel the issue is more fundamental. HTTP/2 shares statelessness with HTTP/1. It follows that the state of the client must be sent to the server or vice versa.  HTTP/2 can make that process much faster but it's not going to know what state to send without instructions from clients or from servers. We can all make up those instructions one at a time and in our own unique ways or the module experts can come up with a good solution for the common cases.  I'm hoping for the latter ;-)

jjb
 


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Glen
You might find this interesting: https://ma.ttias.be/architecting-websites-http2-era/#comment-10935

(PUSH_PROMISE frame)

Glen.

On 2015/04/16 22:43, John Barton wrote:


On Thu, Apr 16, 2015 at 1:22 PM, Domenic Denicola <[hidden email]> wrote:
From: John Barton [mailto:[hidden email]]

> But the push scenario in your first paragraph would not use the cache either.

Yeah, that's what I was alluding to with the "most naïve" comment.

>  one or the other has to send its information at the outset of a import request, or 

One way of doing this I came up with off the top of my head is to add some kind of "dependency graph version" or hash to the query string. I.e. <script type="module" src="entry.js?1234"></script>. The server can then assume that the client has in its cache version 1234 of the dependency graph, and can push the incremental updates since then (i.e. added or modified files). If parts of the cache were evicted, so that the versioning signal is not entirely accurate, then the penalty is not so bad, as you just fall back to the normal loading process for the evicted subset.

But I feel pretty silly speculating here as I'm not an expert on HTTP/2 techniques, and there are probably other methods that are better in various ways.

Perhaps, but I feel the issue is more fundamental. HTTP/2 shares statelessness with HTTP/1. It follows that the state of the client must be sent to the server or vice versa.  HTTP/2 can make that process much faster but it's not going to know what state to send without instructions from clients or from servers. We can all make up those instructions one at a time and in our own unique ways or the module experts can come up with a good solution for the common cases.  I'm hoping for the latter ;-)

jjb
 



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

medikoo
In reply to this post by Domenic Denicola
Thanks for clarifications,

Still after reading your comments I have a feeling that providing ES6 modules to browsers (efficient way) will be much more cumbersome and tricky than it is to provide CJS ones now.
This may lead to scenario when most of us (for easy serve of bundle), will prefer to transpile them into something else, but I hope that won't be the case.

Another question raises about server support. People are relying on shared (or in cloud) hosting solutions. Do all popular servers (Apache, nginx, or http server in node.js) support HTTP/2 already? Is it easy to configure them to serve es6 modules efficient way?

Reply | Threaded
Open this post in threaded view
|

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

Calvin Metcalf

Neither node.js/iojs nor nginx. Though nginx supports spdy and there is a http2 module for node but it isn't compatible with express.


On Fri, Apr 17, 2015, 2:31 AM medikoo <[hidden email]> wrote:
Thanks for clarifications,

Still after reading your comments I have a feeling that providing ES6
modules to browsers (efficient way) will be much more cumbersome and tricky
than it is to provide CJS ones now.
This may lead to scenario when most of us (for easy serve of bundle), will
prefer to transpile them into something else, but I hope that won't be the
case.

Another question raises about server support. People are relying on shared
(or in cloud) hosting solutions. Do all popular servers (Apache, nginx, or
http server in node.js) support HTTP/2 already? Is it easy to configure them
to serve es6 modules efficient way?





--
View this message in context: http://mozilla.6506.n7.nabble.com/Fwd-Are-ES6-modules-in-browsers-going-to-get-loaded-level-by-level-tp337040p338232.html
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

John Barton
In reply to this post by medikoo


On Thu, Apr 16, 2015 at 11:16 PM, medikoo <[hidden email]> wrote:
Thanks for clarifications,

Still after reading your comments I have a feeling that providing ES6
modules to browsers (efficient way) will be much more cumbersome and tricky
than it is to provide CJS ones now.

There is no technological reason to have such a feeling. The design of the ES6 module system makes creating bundles much easier and with much less chance of error. All of the imports can be computed from a given root module without relying on the developer build a list or organizing the bundle inputs into folders.  This is not true for CJS.

jjb

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Matthew Phillips
In reply to this post by Wizek

Can you clarify what you mean about bundling? Unless I've missed something, the ES6 module system does not have a story for bundling at all. Of course formats can be invented in userland but I'm not sure that they are any easier to implement than say AMD's.  I might have missed something though, looking forward to your reply.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Frankie Bagnardi
Matthew, there are already tools for es6 modules + bundling (e.g. babel + webpack), or converting es6 modules to AMD (e.g. babel). 



On Wed, Apr 22, 2015 at 7:10 PM, Matthew Phillips <[hidden email]> wrote:

Can you clarify what you mean about bundling? Unless I've missed something, the ES6 module system does not have a story for bundling at all. Of course formats can be invented in userland but I'm not sure that they are any easier to implement than say AMD's.  I might have missed something though, looking forward to your reply.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Eric B
So just to clarify, when browsers support es6 modules we will still need some extra library to bundle the modules?  This would mean es6 modules are only a syntactical addition and not something functional?

On Thu, Apr 23, 2015 at 10:18 AM Frankie Bagnardi <[hidden email]> wrote:
Matthew, there are already tools for es6 modules + bundling (e.g. babel + webpack), or converting es6 modules to AMD (e.g. babel). 



On Wed, Apr 22, 2015 at 7:10 PM, Matthew Phillips <[hidden email]> wrote:

Can you clarify what you mean about bundling? Unless I've missed something, the ES6 module system does not have a story for bundling at all. Of course formats can be invented in userland but I'm not sure that they are any easier to implement than say AMD's.  I might have missed something though, looking forward to your reply.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Frankie Bagnardi
In 10 years, we probably won't be using tools for the modules added in ES2015, but we might be using them for the changes made in ES2020.

On Thu, Apr 23, 2015 at 7:24 AM, Eric B <[hidden email]> wrote:
So just to clarify, when browsers support es6 modules we will still need some extra library to bundle the modules?  This would mean es6 modules are only a syntactical addition and not something functional?

On Thu, Apr 23, 2015 at 10:18 AM Frankie Bagnardi <[hidden email]> wrote:
Matthew, there are already tools for es6 modules + bundling (e.g. babel + webpack), or converting es6 modules to AMD (e.g. babel). 



On Wed, Apr 22, 2015 at 7:10 PM, Matthew Phillips <[hidden email]> wrote:

Can you clarify what you mean about bundling? Unless I've missed something, the ES6 module system does not have a story for bundling at all. Of course formats can be invented in userland but I'm not sure that they are any easier to implement than say AMD's.  I might have missed something though, looking forward to your reply.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

John Barton
In reply to this post by Matthew Phillips
Correct, ES6 has no plans for a bundling solution and the whatwg group working on the loader has not proposed one.  

Nevertheless  bundling solution is easier to build and specify. In ES6, given a root module you can compute the (static) dependency graph as the basis for creating a bundle.  The bundle will be complete and -- if the code has no unnecessary imports -- minimal.  Moreover, the unnecessary imports can be determined by parser analysis alone. 

Since bundling includes issues of transport,  compression, and minification, I suspect that a standard may not emerge any time soon. Rather I expect a few tools to emerge and these will become de facto standards for bundling.

jjb


On Wed, Apr 22, 2015 at 7:10 PM, Matthew Phillips <[hidden email]> wrote:

Can you clarify what you mean about bundling? Unless I've missed something, the ES6 module system does not have a story for bundling at all. Of course formats can be invented in userland but I'm not sure that they are any easier to implement than say AMD's.  I might have missed something though, looking forward to your reply.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Domenic Denicola
In reply to this post by Eric B

Indeed, there is no built-in facility for bundling since as explained in this thread that will actually slow down your performance, and there’s no desire to include an antipattern in the language.

 

From: es-discuss [mailto:[hidden email]] On Behalf Of Eric B
Sent: Thursday, April 23, 2015 10:25
To: Frankie Bagnardi; Matthew Phillips
Cc: es-discuss
Subject: Re: Re: Are ES6 modules in browsers going to get loaded level-by-level?

 

So just to clarify, when browsers support es6 modules we will still need some extra library to bundle the modules?  This would mean es6 modules are only a syntactical addition and not something functional?

 

On Thu, Apr 23, 2015 at 10:18 AM Frankie Bagnardi <[hidden email]> wrote:

Matthew, there are already tools for es6 modules + bundling (e.g. babel + webpack), or converting es6 modules to AMD (e.g. babel). 

 

 

 

On Wed, Apr 22, 2015 at 7:10 PM, Matthew Phillips <[hidden email]> wrote:


Can you clarify what you mean about bundling? Unless I've missed something, the ES6 module system does not have a story for bundling at all. Of course formats can be invented in userland but I'm not sure that they are any easier to implement than say AMD's.  I might have missed something though, looking forward to your reply.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

 

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Erik Arvidsson

To add one more option. You can create a service worker that loads a single zip file from the server and then splits it up for the client.


On Thu, Apr 23, 2015, 10:48 Domenic Denicola <[hidden email]> wrote:

Indeed, there is no built-in facility for bundling since as explained in this thread that will actually slow down your performance, and there’s no desire to include an antipattern in the language.

 

From: es-discuss [mailto:[hidden email]] On Behalf Of Eric B
Sent: Thursday, April 23, 2015 10:25
To: Frankie Bagnardi; Matthew Phillips
Cc: es-discuss
Subject: Re: Re: Are ES6 modules in browsers going to get loaded level-by-level?

 

So just to clarify, when browsers support es6 modules we will still need some extra library to bundle the modules?  This would mean es6 modules are only a syntactical addition and not something functional?

 

On Thu, Apr 23, 2015 at 10:18 AM Frankie Bagnardi <[hidden email]> wrote:

Matthew, there are already tools for es6 modules + bundling (e.g. babel + webpack), or converting es6 modules to AMD (e.g. babel). 

 

 

 

On Wed, Apr 22, 2015 at 7:10 PM, Matthew Phillips <[hidden email]> wrote:


Can you clarify what you mean about bundling? Unless I've missed something, the ES6 module system does not have a story for bundling at all. Of course formats can be invented in userland but I'm not sure that they are any easier to implement than say AMD's.  I might have missed something though, looking forward to your reply.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

 

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

James Burke-5
In reply to this post by Domenic Denicola
On Thu, Apr 23, 2015 at 7:47 AM, Domenic Denicola <[hidden email]> wrote:

Indeed, there is no built-in facility for bundling since as explained in this thread that will actually slow down your performance, and there’s no desire to include an antipattern in the language.

 



Some counterpoint:

For privileged/certified FirefoxOS apps, they are delivered as zip files right now. No HTTP involved. Asking for multiple files from these local packages was still slower than fetching one file with scripts bundled, due to slower IO on devices, so the certified apps in FirefoxOS right now still do bundling for speed concerns. No network in play, just file IO.

With service workers, it is hard to see that also being faster since the worker needs to be consulted for every request, so in that FirefoxOS app case, I would still want bundling.

With HTTP2, something still needs to do the same work as bundling, where it traces the dependencies and builds a graph so that all the modules in that graph can be sent back in the HTTP2 connection.

So the main complexity of bundling, a "build" step that traces dependencies and makes a graph, is still there. Might as well bundle them so that even when serving from browser cache it will be faster, see device IO concerns above.

Plus, bundling modules together can be more than just a speed concern: a library may want to use modules in separate files and then bundle them into one file for easier encapsulation/distribution.

I am sure the hope is that package managers may help for the distribution case, but this highlights another use related to bundling: encapsulation. Just like nested functions are allowed in the language, nested module definitions make sense long term. Both functions and modules are about reusing units of code. Ideally both could be nested.

I believe that is a bigger design hurdle to overcome and maybe that also made it harder for the module champions to consider any sort of bundling, but bundling really is a thing, and it is unfortunate it is not natively supported for ES modules.

The fun part about leaving this to transpilers is trying to emulate the mutable slots for import identifiers. I think it may work by replacing the identifiers with `loader.get('id').exportName`, or whatever the module meta/loader APIs might be, so having those APIs are even more important for a usable module system. There is probably more nuance to the transformation than that though. Like making sure to add in "use strict" to the function wrapper.

It is kind of sad that to use ES modules means to actually not really use them at runtime, to transpile back to ES5-level of code, and needing to ship a bootstrap loader script that allows slotting that the ES5-level code into the ES loader. For the extra script and transpiling concerns, it does not seem like an improvement over an existing ES5-based module systems.

James



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12