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: Trailing commas in arguments list, imports and destructuring
See https://github.com/tc39/ecma262. This proposal is currently at stage
one. To find out more about what that means, read the process document
https://docs.google.com/document/d/1QbEE0BsO4lvl7NFTn5WXWeiEIBfaVUF7Dk0hpPpPDzU
.
On Wed, Apr 22, 2015 at 8:15 AM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
I just noticed that Babel support trailing commas in function arguments
lists, imports and destructuring as well:
http://babeljs.io/repl/#?experimental=trueevaluate=trueloose=falsespec=falsecode=import%20%7B%0A%20%20voo%2C%0A%20%20doo%2C%0A%7D%20from%20%22.%2Fdat.js%22%3B%0A%0Alet%20%7B%0A%20%20x%2C%0A%20%20y%2C%0A%7D%20%3D%20voo%3B%0A%0Alet%20%5B%0A%20%20z%2C%0A%20%20m%2C%0A%5D%20%3D%20doo%3B%0A%0Afunction%20qoo%20(%0A%20%20x%2C%0A%20%20y%2C%0A)%20%7B%7D
Is this correct behavior? I'm not
FWIW as I already use trailing commas object and array literals for better
diffs, I really like this feature as it comes in handy especially in
function signatures where you define types (TypeScript/flow style
annotations), for example:
function sort T (
array : ArrayT,
compareFn : ((left: T, right: T) = number),
) : ArrayT {
...
}
as well as import statements for modules that declare constants:
import {
BRAND_COLOR,
DEFAULT_TEXT_COLOR,
DARK_GRAY,
LIGHT_GRAY,
} from ./constants/COLORS;
not to mention options object style function signatures:
class Person {
constructor ({
firstName,
lastName,
birthDate,
country,
city,
zipCode,
}) {
this.firstName = firstName;
this.lastName = lastName;
this.birthDate = birthDate;
this.country = country;
this.city = city;
this.zipCode = zipCode;
}
}
To me, the spec language as per Jason's HTML version looks like at least
for destructuring this is supported, but at least I can't read the spec to
allow trailing commas in function signatures. At least this doesn't seem to
be incorporated into the spec:
https://esdiscuss.org/notes/2014-09/trailing_comma_proposal.pdf
Is the proposal still on track for ES7 and am I correct in my reading of
the destructuring allowing trailing commas?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Shape Security is hiring outstanding individuals. Check us out at
*https://shapesecurity.com/jobs/
https://shapesecurity.com/jobs/*
___
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: Are ES6 modules in browsers going to get loaded level-by-level?
James Burke wrote: 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. Your lament poses a question that answers itself: in time, ES6 will be the base level, not ES3 or ES5. Then, the loader can be nativized. Complaining about this now seems churlish. :-| /be ___ 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
Subclassing ES6 objects with ES5 syntax.
Is there any way to access `new.target` using ES5 syntax?
It appears that the correct way to create a subclass using ES5 syntax is:
```
function MyPromise(executor) {
var self = Reflect.construct(Promise, [executor], new.target);
return self;
}
Object.setPrototypeOf(MyPromise, Promise);
```
But since `new.target` isn't accessible, we have to do something like:
```
function MyPromise(executor) {
var self = Reflect.construct(Promise, [executor], MyPromise); // -- THIS
return self;
}
Object.setPrototypeOf(MyPromise, Promise);
```
which works for only a single level of subclassing. That is, it allows us
to create and instantiate MyPromise, but now nobody can subclass
MyPromise. That's too bad.
Is there any way around this?
--scott
ps. Use case: My `prfun` package on npm subclasses `Promise` in order to
add all the useful utility helpers without stomping on the global `Promise`
object. I'd like to do so in a way which is compatible with both native
ES6 promises (if they are available) and properly-written ES5 shims.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Subclassing ES6 objects with ES5 syntax.
new.target is available in functions.
On Thu, Apr 23, 2015, 21:02 C. Scott Ananian ecmascr...@cscott.net wrote:
Is there any way to access `new.target` using ES5 syntax?
It appears that the correct way to create a subclass using ES5 syntax is:
```
function MyPromise(executor) {
var self = Reflect.construct(Promise, [executor], new.target);
return self;
}
Object.setPrototypeOf(MyPromise, Promise);
```
But since `new.target` isn't accessible, we have to do something like:
```
function MyPromise(executor) {
var self = Reflect.construct(Promise, [executor], MyPromise); // -- THIS
return self;
}
Object.setPrototypeOf(MyPromise, Promise);
```
which works for only a single level of subclassing. That is, it allows us
to create and instantiate MyPromise, but now nobody can subclass
MyPromise. That's too bad.
Is there any way around this?
--scott
ps. Use case: My `prfun` package on npm subclasses `Promise` in order to
add all the useful utility helpers without stomping on the global `Promise`
object. I'd like to do so in a way which is compatible with both native
ES6 promises (if they are available) and properly-written ES5 shims.
___
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: Subclassing ES6 objects with ES5 syntax.
So, why exactly is SuperCall forbidden in function bodies? If people work
around it with Reflect.construct anyways, it just seems nice to use SuperCall
instead — at least if new.target is defined
On Apr 23, 2015, at 9:24 PM, Erik Arvidsson erik.arvids...@gmail.com wrote:
new.target is available in functions.
On Thu, Apr 23, 2015, 21:02 C. Scott Ananian ecmascr...@cscott.net
mailto:ecmascr...@cscott.net wrote:
Is there any way to access `new.target` using ES5 syntax?
It appears that the correct way to create a subclass using ES5 syntax is:
```
function MyPromise(executor) {
var self = Reflect.construct(Promise, [executor], new.target);
return self;
}
Object.setPrototypeOf(MyPromise, Promise);
```
But since `new.target` isn't accessible, we have to do something like:
```
function MyPromise(executor) {
var self = Reflect.construct(Promise, [executor], MyPromise); // -- THIS
return self;
}
Object.setPrototypeOf(MyPromise, Promise);
```
which works for only a single level of subclassing. That is, it allows us to
create and instantiate MyPromise, but now nobody can subclass MyPromise.
That's too bad.
Is there any way around this?
--scott
ps. Use case: My `prfun` package on npm subclasses `Promise` in order to add
all the useful utility helpers without stomping on the global `Promise`
object. I'd like to do so in a way which is compatible with both native ES6
promises (if they are available) and properly-written ES5 shims.
___
es-discuss mailing list
es-discuss@mozilla.org mailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
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?
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: Are ES6 modules in browsers going to get loaded level-by-level?
On Thu, Apr 23, 2015 at 4:48 PM, Brendan Eich bren...@mozilla.org wrote: Your lament poses a question that answers itself: in time, ES6 will be the base level, not ES3 or ES5. Then, the loader can be nativized. Complaining about this now seems churlish. :-| So let's stay on this specific point: bundling will still be done even with ES modules and a loader that would natively understand ES modules in unbundled form. Hopefully the rest of my previous message gave enough data as to why. If not natively supported in ES, it would be great to get a pointer to the officially blessed transform of an ES module body to something that can be bundled. Something that preserves the behaviors of the mutable slots, and allows using the module meta. James ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
