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 <dome...@domenicdenicola.com>
wrote:
> From: es-discuss <es-discuss-boun...@mozilla.org> on behalf of James Burke
> <jrbu...@gmail.com>
>
>> 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
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
