TC39 vs "the community"

David Bruant bruant.d at
Fri Jun 20 02:32:05 PDT 2014


I'm not quite sure what this is all about, so forking in hope for 
I'm sorry to send a message that will probably be read as noise by a lot 
of people, but I'm also tired of some of these pointless and 
unconstructive, if not destructive, fights among people (in here, on 
Twitter or elsewhere).
I hope to have a conversation to start the end of the alleged 
unharmonious relationship between TC39 and JS developers.

Domenic, your email suggests a fairly strong dichotomy between "TC39" 
and "the community". As far as I'm concerned, to begin with, I don't see 
anything that is called "the community" in JavaScript. I join Axel's 
point of view. I see lots of communities with different backgrounds and 
interests, especially among the JS devs.
I personnally don't feel associated with "the community" you describe. I 
encourage you to either speak only for yourself or provide a more 
specific description of whose point of view you're referring to 
(preferably without a definite article).

Le 19/06/2014 21:13, Domenic Denicola a écrit :
> Unfortunately, that's not the world we live in, and instead TC39 is designing a module system based on their own priorities. (Static checking of multi-export names, mutable bindings, etc.)
If I knew nothing about how ES standardization works, I'd be thinking 
"who the fuck are these TC39 people who decide features based on their 
own agenda against the interest/experience of the developers? Who do 
they think they are anyway?"

Can you develop these particular accusations?
Why would TC39 have priorities that don't align with the needs of 
developers? especially on modules which are clearly one of the most 
awaited feature as far as developers are concerned?

I'm not quite sure I understand the dichotomy and the alleged TC39 
priorities that would be that far off from what JS devs otherwse need, 
so please get it off your chest so we can all move on.

> They've (wisely) decided to add affordances for the community's use cases, such as layering default exports on top of the multi-export model. As well as Dave's proposal in this thread to de-grossify usage of modules like "fs". By doing so, they increase their chances of the module system being "good enough" for the community, so that the path of least resistance will be to adopt it, despite it not being designed for them primarily. It's still an open question whether this will be enough to win over the community from their existing tools, but with Dave's suggestion I think it has a better-than-even chance.
> 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. We already see signs of community interest in such "ES6+" transpilers, as Angular illustrates. Even a transpiler that maintains a subset of ES6 syntax would work: if it supported only `export default x`, and then gave `import { x } from "y"` destructuring semantics instead of named-binding-import semantics, that would do the trick. Interesting times.
Whatever TC39 settles in and is eventually part of the standard will 
inevitably have tooling associated to it. Maybe not by "the community" 
(whoever that is), but I'm fairly certain TypeScript will adopt it for 
instance. I'm fairly sure IDEs will all eventually have syntactic or 
"intelligent" support of the official standard modules (which is less 
clear for whatever-transpiler-modules).
Some people who aren't part of "the community" will write code in ES6 
modules. Whatever they end up being, I'll probably be on that end pretty 
much for the same reason I choose to not write coffeescript (because 
AFAIC my own taste in code has less worth than other's ability to 
understand the code I write).

Whatever they end up looking and behaving, ES6 modules will happen with 
"the community" or without it.


More information about the es-discuss mailing list