Hi,
I'm not quite sure what this is all about, so forking in hope for
clarifications.
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.
David
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
