All good points. I don’t see “TC39 versus the community”, though, I’m seeing many factions with different opinions.
On Jun 19, 2014, at 21:13 , Domenic Denicola <[email protected]> wrote: > From: es-discuss <[email protected]> on behalf of James Burke > <[email protected]> > >> 1) Only allow export default or named exports, not both. > > As a modification of the current design, this hurts use cases like > > ```js > import glob, { sync as syncGlob } from "glob"; > import _, { zip } from "underscore"; > ``` > >> 2) Only allow `export` of one thing from a module, and `import {}` just >> means allowing getting the first property on that export. This removes the >> named export checking, but that benefit was always a bit weak, even weaker >> with the favoring of default export. > > I definitely believe that if the community were designing a syntax-based > module format, incorporating the lessons learned so far, it would end up > being along these lines. We've learned enough from browserify and RequireJS's > CommonJS-wrapping to know that a top-level static import form has serious > benefits, but we've also learned that `module.exports =` or `return` are the > recommended and primary pattern, and you can always attach things to that > "default export" as properties if necessary. (In CommonJS terms, we've > learned that the benefits of typing `exports.x = y` instead of > `module.exports.x = y` are not great enough to outweigh the minor confusion > of having two export forms.) > > 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.) > > 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. > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > -- Dr. Axel Rauschmayer [email protected] rauschma.de
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
