Re: Re: Are ES6 modules in browsers going to get loaded level-by-level?
Right, exactly. So naively sending all dependencies wastefully is just the first step. > Afaik the more promising path are prefetch hints on the client. E.g. the client (or initial HTML payload) knows the dependency tree, adds tags for preloading the required modules, and then the browser can properly handle fine-grained caching from there, only requesting what is actually needed. That may be nice, but I imagine people importing libraries from different domains (without knowing the graphs, for example, in simple codepen or jsfiddle demos with no build tooling). So suppose the client code consists only of one single line of HTML, just ```html
Re: Re: Are ES6 modules in browsers going to get loaded level-by-level?
> If I understand HTTP/2 correctly, this requires more than a server > that simply has HTTP push, it requires a server that understands how > to read ES modules and enumerate their dependencies. Not only that: The server also has to "know" which modules are already cached by the client (including potential match/modified-since logic). If the server always sends _all_ modules in the dependency graph, then it's just a less efficient bundle of all modules. Afaik the more promising path are prefetch hints on the client. E.g. the client (or initial HTML payload) knows the dependency tree, adds tags for preloading the required modules, and then the browser can properly handle fine-grained caching from there, only requesting what is actually needed. Cheers, Jan On Mon, Oct 12, 2020 at 12:59 PM #!/JoePea wrote: > I'm asking about a server that, upon request of a `.js` file, knows > how to enumerate the dependency tree based on that file, _then_ HTTP > pushes all the modules at once. > > So basically, from the code > > ```html >
Re: Re: Are ES6 modules in browsers going to get loaded level-by-level?
I'm asking about a server that, upon request of a `.js` file, knows how to enumerate the dependency tree based on that file, _then_ HTTP pushes all the modules at once. So basically, from the code ```html
Re: Re: Are ES6 modules in browsers going to get loaded level-by-level?
On Sat, Oct 10, 2020 at 5:19 PM #!/JoePea wrote: > It's 5 years later, but still no (obvious) sign of HTTP/2 servers > specialized in ES Module push. > What does it mean to specialize in module push? How can modules be pushed without the browser requesting them? Is it a server that reads the scripts and pre-feeds the scripts? > > Do any exist? Anyone have a list? I'm especially interested in the > self-hostable servers, but also curious about solutions where we may > publish modules to. > > The non-self-hosted solutions may be attractive to those people who > normally publish static sites and need to publish ES Modules as static > resources somewhere without the fuss if managing a server. > > Oh - it's to update into the server? J > > #!/JoePea > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Are ES6 modules in browsers going to get loaded level-by-level?
It's 5 years later, but still no (obvious) sign of HTTP/2 servers specialized in ES Module push. Do any exist? Anyone have a list? I'm especially interested in the self-hostable servers, but also curious about solutions where we may publish modules to. The non-self-hosted solutions may be attractive to those people who normally publish static sites and need to publish ES Modules as static resources somewhere without the fuss if managing a server. #!/JoePea ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Are ES6 modules in browsers going to get loaded level-by-level?
Replies interspersed below
On Thu, Apr 23, 2015 at 9:48 AM, James Burke jrbu...@gmail.com wrote:
On Thu, Apr 23, 2015 at 7:47 AM, Domenic Denicola d...@domenic.me 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.
If we're just talking about scripts, why not simply cache the entire zip
file on the client end? That way there'd be only one request to the
service worker (and perhaps queries to see if the zip's been updated).
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.
There's one big advantage of not bundling: debugging tools. Chrome's
debugger is much more stable than it used to be (I've not tried Firefox for
a long time), to the point that being able to load one's scripts in their
original form and map them to their location on the file system is quite
nice (you can then live edit scripts in Chrome DevTools, which is
unbelievably nice, you have no idea).
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.
Right. Bundling libraries for release builds makes perfect sense.
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
Syntactically it's quite nice, though. IMHO, even if it's just syntactic
sugar it's still worth it. I remember thinking the grammar was insane when
I implemented it, but after using es6 modules for a while I now think
they're (far) superior to even python's approach, at least in terms of
usability.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Are ES6 modules in browsers going to get loaded level-by-level?
What I do is send the files over in as TAR archives, with mod_deflate turned on (they basically turn into .tar.gz files at that point). It's reasonably fast, even though I'm processing thirty megabytes of data this way (yay for typed arrays). I highly recommend it. On Thu, Apr 23, 2015 at 7:57 AM, Erik Arvidsson erik.arvids...@gmail.com wrote: 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 d...@domenic.me 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:es-discuss-boun...@mozilla.org] *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 f.bagna...@gmail.com wrote: Matthew, there are already tools for es6 modules + bundling (e.g. babel + webpack), or converting es6 modules to AMD (e.g. babel https://babeljs.io/docs/usage/modules/). On Wed, Apr 22, 2015 at 7:10 PM, Matthew Phillips matt...@bitovi.com 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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Re: Are ES6 modules in browsers going to get loaded level-by-level?
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:es-discuss-boun...@mozilla.org] 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 f.bagna...@gmail.commailto:f.bagna...@gmail.com wrote: Matthew, there are already tools for es6 modules + bundling (e.g. babel + webpack), or converting es6 modules to AMD (e.g. babelhttps://babeljs.io/docs/usage/modules/). On Wed, Apr 22, 2015 at 7:10 PM, Matthew Phillips matt...@bitovi.commailto:matt...@bitovi.com 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 es-discuss@mozilla.orgmailto:es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.orgmailto:es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Are ES6 modules in browsers going to get loaded level-by-level?
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 neuros...@gmail.com 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 f.bagna...@gmail.com wrote: Matthew, there are already tools for es6 modules + bundling (e.g. babel + webpack), or converting es6 modules to AMD (e.g. babel https://babeljs.io/docs/usage/modules/). On Wed, Apr 22, 2015 at 7:10 PM, Matthew Phillips matt...@bitovi.com 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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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 f.bagna...@gmail.com wrote: Matthew, there are already tools for es6 modules + bundling (e.g. babel + webpack), or converting es6 modules to AMD (e.g. babel https://babeljs.io/docs/usage/modules/). On Wed, Apr 22, 2015 at 7:10 PM, Matthew Phillips matt...@bitovi.com 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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Are ES6 modules in browsers going to get loaded level-by-level?
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 d...@domenic.me 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:es-discuss-boun...@mozilla.org] *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 f.bagna...@gmail.com wrote: Matthew, there are already tools for es6 modules + bundling (e.g. babel + webpack), or converting es6 modules to AMD (e.g. babel https://babeljs.io/docs/usage/modules/). On Wed, Apr 22, 2015 at 7:10 PM, Matthew Phillips matt...@bitovi.com 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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Are ES6 modules in browsers going to get loaded level-by-level?
Matthew, there are already tools for es6 modules + bundling (e.g. babel + webpack), or converting es6 modules to AMD (e.g. babel https://babeljs.io/docs/usage/modules/). On Wed, Apr 22, 2015 at 7:10 PM, Matthew Phillips matt...@bitovi.com 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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Are ES6 modules in browsers going to get loaded level-by-level?
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 matt...@bitovi.com 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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Are ES6 modules in browsers going to get loaded level-by-level?
On Thu, Apr 23, 2015 at 7:47 AM, Domenic Denicola d...@domenic.me 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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Are ES6 modules in browsers going to get loaded level-by-level?
Sorry, but what I read was not an explanation but rather a hope that HTTP/2 would magically solve this problem. I'm all for HTTP/2 solving this. But so far I've not heard or read anything to back up the idea. Will HTTP/2 make multiple round trips, one for each level of the dependency tree, competitive with pre-bundling? If not, then we will have to send dependency info to the client or cache info to the server or bundle. Or there is some magic as yet unexplained? jjb On Thu, Apr 23, 2015 at 7:47 AM, Domenic Denicola d...@domenic.me 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:es-discuss-boun...@mozilla.org] *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 f.bagna...@gmail.com wrote: Matthew, there are already tools for es6 modules + bundling (e.g. babel + webpack), or converting es6 modules to AMD (e.g. babel https://babeljs.io/docs/usage/modules/). On Wed, Apr 22, 2015 at 7:10 PM, Matthew Phillips matt...@bitovi.com 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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Are ES6 modules in browsers going to get loaded level-by-level?
It would be great if the web app manifest included the dependency graph for the app. Something like the depCache in system js. On Apr 23, 2015 8:03 PM, Matthew Phillips matt...@bitovi.com wrote: I think the issue of round-trips is a red-herring. I spent some effort trying to optimize an es6 loader with caching in indexeddb and even that did not help much. I think what caridy said earlier is likely the biggest issue, processing a large number of Promises. On Thu, Apr 23, 2015 at 7:55 PM, John Barton johnjbar...@google.com wrote: Sorry, but what I read was not an explanation but rather a hope that HTTP/2 would magically solve this problem. I'm all for HTTP/2 solving this. But so far I've not heard or read anything to back up the idea. Will HTTP/2 make multiple round trips, one for each level of the dependency tree, competitive with pre-bundling? If not, then we will have to send dependency info to the client or cache info to the server or bundle. Or there is some magic as yet unexplained? jjb On Thu, Apr 23, 2015 at 7:47 AM, Domenic Denicola d...@domenic.me 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:es-discuss-boun...@mozilla.org] *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 f.bagna...@gmail.com wrote: Matthew, there are already tools for es6 modules + bundling (e.g. babel + webpack), or converting es6 modules to AMD (e.g. babel https://babeljs.io/docs/usage/modules/). On Wed, Apr 22, 2015 at 7:10 PM, Matthew Phillips matt...@bitovi.com 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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Bitovi Development | Design | Training | Open Source ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Are ES6 modules in browsers going to get loaded level-by-level?
I think the issue of round-trips is a red-herring. I spent some effort trying to optimize an es6 loader with caching in indexeddb and even that did not help much. I think what caridy said earlier is likely the biggest issue, processing a large number of Promises. On Thu, Apr 23, 2015 at 7:55 PM, John Barton johnjbar...@google.com wrote: Sorry, but what I read was not an explanation but rather a hope that HTTP/2 would magically solve this problem. I'm all for HTTP/2 solving this. But so far I've not heard or read anything to back up the idea. Will HTTP/2 make multiple round trips, one for each level of the dependency tree, competitive with pre-bundling? If not, then we will have to send dependency info to the client or cache info to the server or bundle. Or there is some magic as yet unexplained? jjb On Thu, Apr 23, 2015 at 7:47 AM, Domenic Denicola d...@domenic.me 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:es-discuss-boun...@mozilla.org] *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 f.bagna...@gmail.com wrote: Matthew, there are already tools for es6 modules + bundling (e.g. babel + webpack), or converting es6 modules to AMD (e.g. babel https://babeljs.io/docs/usage/modules/). On Wed, Apr 22, 2015 at 7:10 PM, Matthew Phillips matt...@bitovi.com 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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Bitovi Development | Design | Training | Open Source ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Are ES6 modules in browsers going to get loaded level-by-level?
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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
