ModuleImport

Axel Rauschmayer axel at rauschma.de
Thu Jun 19 12:32:24 PDT 2014


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 <domenic at domenicdenicola.com> wrote:

> From: es-discuss <es-discuss-bounces at mozilla.org> on behalf of James Burke <jrburke at 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 at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 

-- 
Dr. Axel Rauschmayer
axel at rauschma.de
rauschma.de



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140619/395007cf/attachment-0001.html>


More information about the es-discuss mailing list