On Thu, Jun 19, 2014 at 8:48 PM, Brendan Eich <brendan at mozilla.org> wrote:

Domenic Denicola wrote:
>
>> The transitional era will be a particularly vulnerable time for TC39's
>> module design, however: as long as people are using transpilers, there's an
>> opportunity for a particularly well-crafted, documented, and supported
>> transpiler to give alternate semantics grounded in the community's
>> preferred model, and win over enough of an audience to bleed the life out
>> of TC39's modules.
>>
>
> You're doing a disservice to everyone here by implying that such a
> transpiler could trump native modules as implemented per the normative ES6
> spec in Chakra, JSC, SpiderMonkey, and V8.
>
> Idle speculations are not even worth betting on, but filling es-discuss
> with tendentious idle speculations is worse. Cut it out.

Domenic may have erred by conflating many different constituencies into a
monolithic, definite version of “the community”, but I don’t think his
characterization of a “transitional era” or the risks therein are
tendentious. Some people on es-discuss (including, at times, Domenic) seem
to assume that Node.js developers will embrace ES6 part and parcel, when
the feedback I receive on a daily basis is very different. (As I’m
primarily a Node developer, I can’t speak to the concerns of other groups
within the broader JS community, but I do think the feedback coming from
e.g. James Burke is valuable here.)

I bring up these concerns not because I agree with them, but because I feel
awkward about the disconnect between the message I see coming out of TC39
and the response from my friends and peers. I’m also concerned about
schisms happening within the Node community, especially if the team
developing the platform and the broader developer community find themselves
at odds when it comes to module systems. That said, there are two
overarching themes that tend to come up in discussions among Node
developers when the ES6 module system is discussed:
1. Node’s module system is frozen.

There has long been an ideology within Node that there will be a point at
which it is “finished”, and at that point the platform / kernel will have a
frozen API and all of the innovation around Node will happen in the module
ecosystem. The forcing function for this is Node’s stability index
<http://nodejs.org/api/documentation.html#documentation_stability_index>,
which is a ratchet much like the ES7 design process, where once a piece of
the platform attains a higher level of stability, it can’t move to a lower
one.

The module system is one of the few pieces of Node that has the highest,
locked level of stability. This is in part because it’s the piece that
connects Node to npm and the module ecosystem. It has also long been the
locus of long and difficult debates
<https://github.com/joyent/node/issues/6960>, and getting the module system
to the locked state was a key move in fostering the active growth of the
Node ecosystem, even though (as that thread shows) it clearly still has
unresolved issues.

I can see a future in which ES6 modules are a part of V8 and therefore
included in Node, and also where somebody builds a module loader that maps
ES6 modules onto the Node module loader. Projects like jspm
<http://jspm.io/> are interesting in this regard, but this is all being
done in the context of a “finished” module system, so there’s a deep
skepticism (sometimes bordering on dismissiveness) on the part of Node’s
core development team that moving Node to using ES6 modules by default is a
thing that could even happen.
2. Node’s modules are good enough for all use cases.

This is obviously a subjective statement that’s burdened with a large load
of implicit assumptions, but it’s one I see a lot, especially from the
community built up around browserify. Node’s core APIs tend to use
multi-export because they’re themed grab bags (fs, util, os, etc), but the
community has converged on single-export / single-purpose modules as the
dominant convention for library development. Because CommonJS modules are
just a protocol built atop plain JS objects, Node’s module system is easily
flexible enough to support both styles of export, and both are entrenched.
Any new proposal that ditches or deprecates either of these styles is
therefore nearly guaranteed to cause dismay, which is (I believe) what
happened when the notes from the module side discussion from the last face
to face started circulating.

It also shows how high the bar is set when it comes to the Node community
switching module systems. There’s little question in my mind that
browser-first developers who aren’t heavily invested in AMD will move en
masse to whatever ends up being in ES6 (and I believe that this comprises a
majority of working JavaScript developers). I do believe that unless the
path from Node to ES6 modules is painless, and unless the Node community
sees clear value in making the switch, they’re just not going to bother.

Maybe this is fine! Transpilers exist, and browserify isn’t going anywhere.
But I see people here evangelizing the new system, and occasionally acting
as if they believe that *everybody* is going to switch to ES6 modules, and
that seems very far from being a foregone conclusion to me. The status quo
before the last face to face was a very delicate compromise that more or
less successfully balanced all the competing requirements from JavaScript’s
various constituencies. Therefore, when a new document shows up that
proposes knocking out one of the load-bearing members of that compromise,
nobody should be surprised when people get upset. (For what it’s worth, I
think Dave Herman’s latest proposal is great, especially because it only
changes syntax, not semantics.)

Domenic has been a big proponent of ES6 within the Node world, and has
tended to err on the side of promoting the view that Node core and the Node
developer community *must* adopt ES6 at the risk of getting left behind. I
don’t feel like he has a particular axe to grind here, he’s just more
attuned to what’s going on in Node than most of the people on this list,
and is raising what seems like a pretty tempered version of a widely-held
concern. Again, I know the Node world is pretty small in the grand scheme
of things, and I don’t want to misrepresent the breadth of the objections,
but I do think that the risk of fragmentation is significant, and I would
like us to find a way to mitigate that risk if we can.

F
​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140620/4f181fe7/attachment.html>

> On Thu, Jun 19, 2014 at 8:48 PM, Brendan Eich <brendan at mozilla.org> wrote:
>
>> Domenic Denicola wrote:
>>
>> The transitional era will be a particularly vulnerable time for TC39's
>> module design, however: as long as people are using transpilers, there's an
>> opportunity for a particularly well-crafted, documented, and supported
>> transpiler to give alternate semantics grounded in the community's
>> preferred model, and win over enough of an audience to bleed the life out
>> of TC39's modules.
>>
>
> You're doing a disservice to everyone here by implying that such a
> transpiler could trump native modules as implemented per the normative ES6
> spec in Chakra, JSC, SpiderMonkey, and V8.
>
> Idle speculations are not even worth betting on, but filling es-discuss
> with tendentious idle speculations is worse. Cut it out.

Domenic may have erred by conflating many different constituencies into a monolithic, definite version of “the community”, but I don’t think his characterization of a “transitional era” or the risks therein are tendentious. Some people on es-discuss (including, at times, Domenic) seem to assume that Node.js developers will embrace ES6 part and parcel, when
the feedback I receive on a daily basis is very different. (As I’m primarily a Node developer, I can’t speak to the concerns of other groups within the broader JS community, but I do think the feedback coming from e.g. James Burke is valuable here.)

I bring up these concerns not because I agree with them, but because I feel awkward about the disconnect between the message I see coming out of TC39 and the response from my friends and peers. I’m also concerned about schisms happening within the Node community, especially if the team developing the platform and the broader developer community find themselves at odds when it comes to module systems. That said, there are two overarching themes that tend to come up in discussions among Node
developers when the ES6 module system is discussed:

> (1) Node’s module system is frozen.

There has long been an ideology within Node that there will be a point at which it is “finished”, and at that point the platform/kernel will have a frozen API and all of the innovation around Node will happen in the module ecosystem. The forcing function for this is Node’s stability index http://nodejs.org/api/documentation.html#documentation_stability_index, which is a ratchet much like the ES7 design process, where once a piece of the platform attains a higher level of stability, it can’t move to a lower one.

The module system is one of the few pieces of Node that has the highest, locked level of stability. This is in part because it’s the piece that connects Node to npm and the module ecosystem. It has also long been the locus of long and difficult debates https://github.com/joyent/node/issues/6960, and getting the module system to the locked state was a key move in fostering the active growth of the Node ecosystem, even though (as that thread shows) it clearly still has unresolved issues.

I can see a future in which ES6 modules are a part of V8 and therefore included in Node, and also where somebody builds a module loader that maps ES6 modules onto the Node module loader. Projects like jspm <http://jspm.io/> are interesting in this regard, but this is all being done in the context of a “finished” module system, so there’s a deep skepticism (sometimes bordering on dismissiveness) on the part of Node’s core development team that moving Node to using ES6 modules by default is a thing that could even happen.

> (2) Node’s modules are good enough for all use cases.

This is obviously a subjective statement that’s burdened with a large load of implicit assumptions, but it’s one I see a lot, especially from the community built up around browserify. Node’s core APIs tend to use multi-export because they’re themed grab bags (fs, util, os, etc), but the community has converged on single-export / single-purpose modules as the
dominant convention for library development. Because CommonJS modules are just a protocol built atop plain JS objects, Node’s module system is easily flexible enough to support both styles of export, and both are entrenched. Any new proposal that ditches or deprecates either of these styles is therefore nearly guaranteed to cause dismay, which is (I believe) what happened when the notes from the module side discussion from the last face to face started circulating.

It also shows how high the bar is set when it comes to the Node community switching module systems. There’s little question in my mind that browser-first developers who aren’t heavily invested in AMD will move en masse to whatever ends up being in ES6 (and I believe that this comprises a majority of working JavaScript developers). I do believe that unless the path from Node to ES6 modules is painless, and unless the Node community sees clear value in making the switch, they’re just not going to bother.

Maybe this is fine! Transpilers exist, and browserify isn’t going anywhere. But I see people here evangelizing the new system, and occasionally acting as if they believe that *everybody* is going to switch to ES6 modules, and that seems very far from being a foregone conclusion to me. The status quo before the last face to face was a very delicate compromise that more or less successfully balanced all the competing requirements from JavaScript’s various constituencies. Therefore, when a new document shows up that proposes knocking out one of the load-bearing members of that compromise, nobody should be surprised when people get upset. (For what it’s worth, I think Dave Herman’s latest proposal is great, especially because it only changes syntax, not semantics.)

Domenic has been a big proponent of ES6 within the Node world, and has tended to err on the side of promoting the view that Node core and the Node developer community *must* adopt ES6 at the risk of getting left behind. I don’t feel like he has a particular axe to grind here, he’s just more attuned to what’s going on in Node than most of the people on this list, and is raising what seems like a pretty tempered version of a widely-held concern. Again, I know the Node world is pretty small in the grand scheme of things, and I don’t want to misrepresent the breadth of the objections, but I do think that the risk of fragmentation is significant, and I would like us to find a way to mitigate that risk if we can.

F

> On Thu, Jun 19, 2014 at 8:48 PM, Brendan Eich <brendan at mozilla.org> wrote:
>
>> Domenic Denicola wrote:
>>
>> The transitional era will be a particularly vulnerable time for TC39's
>> module design, however: as long as people are using transpilers, there's an
>> opportunity for a particularly well-crafted, documented, and supported
>> transpiler to give alternate semantics grounded in the community's
>> preferred model, and win over enough of an audience to bleed the life out
>> of TC39's modules.
>>
>
> You're doing a disservice to everyone here by implying that such a
> transpiler could trump native modules as implemented per the normative ES6
> spec in Chakra, JSC, SpiderMonkey, and V8.
>
> Idle speculations are not even worth betting on, but filling es-discuss
> with tendentious idle speculations is worse. Cut it out.

Domenic may have erred by conflating many different constituencies into a monolithic, definite version of “the community”, but I don’t think his characterization of a “transitional era” or the risks therein are tendentious. Some people on es-discuss (including, at times, Domenic) seem to assume that Node.js developers will embrace ES6 part and parcel, when
the feedback I receive on a daily basis is very different. (As I’m primarily a Node developer, I can’t speak to the concerns of other groups within the broader JS community, but I do think the feedback coming from e.g. James Burke is valuable here.)

I bring up these concerns not because I agree with them, but because I feel awkward about the disconnect between the message I see coming out of TC39 and the response from my friends and peers. I’m also concerned about schisms happening within the Node community, especially if the team developing the platform and the broader developer community find themselves at odds when it comes to module systems. That said, there are two overarching themes that tend to come up in discussions among Node
developers when the ES6 module system is discussed:

1. Node’s module system is frozen.

There has long been an ideology within Node that there will be a point at which it is “finished”, and at that point the platform/kernel will have a frozen API and all of the innovation around Node will happen in the module ecosystem. The forcing function for this is Node’s stability index http://nodejs.org/api/documentation.html#documentation_stability_index, which is a ratchet much like the ES7 design process, where once a piece of the platform attains a higher level of stability, it can’t move to a lower one.

The module system is one of the few pieces of Node that has the highest, locked level of stability. This is in part because it’s the piece that connects Node to npm and the module ecosystem. It has also long been the locus of long and difficult debates https://github.com/joyent/node/issues/6960, and getting the module system to the locked state was a key move in fostering the active growth of the Node ecosystem, even though (as that thread shows) it clearly still has unresolved issues.

I can see a future in which ES6 modules are a part of V8 and therefore included in Node, and also where somebody builds a module loader that maps ES6 modules onto the Node module loader. Projects like jspm <http://jspm.io/> are interesting in this regard, but this is all being done in the context of a “finished” module system, so there’s a deep skepticism (sometimes bordering on dismissiveness) on the part of Node’s core development team that moving Node to using ES6 modules by default is a thing that could even happen.

2. Node’s modules are good enough for all use cases.

This is obviously a subjective statement that’s burdened with a large load of implicit assumptions, but it’s one I see a lot, especially from the community built up around browserify. Node’s core APIs tend to use multi-export because they’re themed grab bags (fs, util, os, etc), but the community has converged on single-export / single-purpose modules as the
dominant convention for library development. Because CommonJS modules are just a protocol built atop plain JS objects, Node’s module system is easily flexible enough to support both styles of export, and both are entrenched. Any new proposal that ditches or deprecates either of these styles is therefore nearly guaranteed to cause dismay, which is (I believe) what happened when the notes from the module side discussion from the last face to face started circulating.

It also shows how high the bar is set when it comes to the Node community switching module systems. There’s little question in my mind that browser-first developers who aren’t heavily invested in AMD will move en masse to whatever ends up being in ES6 (and I believe that this comprises a majority of working JavaScript developers). I do believe that unless the path from Node to ES6 modules is painless, and unless the Node community sees clear value in making the switch, they’re just not going to bother.

Maybe this is fine! Transpilers exist, and browserify isn’t going anywhere. But I see people here evangelizing the new system, and occasionally acting as if they believe that *everybody* is going to switch to ES6 modules, and that seems very far from being a foregone conclusion to me. The status quo before the last face to face was a very delicate compromise that more or less successfully balanced all the competing requirements from JavaScript’s various constituencies. Therefore, when a new document shows up that proposes knocking out one of the load-bearing members of that compromise, nobody should be surprised when people get upset. (For what it’s worth, I think Dave Herman’s latest proposal is great, especially because it only changes syntax, not semantics.)

Domenic has been a big proponent of ES6 within the Node world, and has tended to err on the side of promoting the view that Node core and the Node developer community *must* adopt ES6 at the risk of getting left behind. I don’t feel like he has a particular axe to grind here, he’s just more attuned to what’s going on in Node than most of the people on this list, and is raising what seems like a pretty tempered version of a widely-held concern. Again, I know the Node world is pretty small in the grand scheme of things, and I don’t want to misrepresent the breadth of the objections, but I do think that the risk of fragmentation is significant, and I would like us to find a way to mitigate that risk if we can.

F