Rationale for dropping ModuleImport syntax?

John Barton johnjbarton at google.com
Mon Jun 9 09:08:32 PDT 2014

On Mon, Jun 9, 2014 at 7:51 AM, Axel Rauschmayer <axel at rauschma.de> wrote:

> I’m assuming that people will default-export objects (for
> Underscore.js-like libraries). I’d call those pseudo-modules, because one
> would be partially working around the module system (no load-time errors!).

Then aren't you arguing against default-export?

> Maybe we’ll import modules like this [^1], but that feels syntactically
> inconsistent to me and you don’t get load-time errors, either:
> ```js
> import "Underscore";
> const _ = System.get("Underscore");
> ```

Seems to me that users will write
import {_} from 'Underscore';
because the underscore team will write their ES6 modules to support this

> [^1]: https://gist.github.com/domenic/2230a7195fa0de31a227

These examples mix issues. If you want to rename a passel of imports, you
necessarily have a passel of renamings to write. That is not the fault of
the module syntax. Similarly, if the module author chooses to export a long
list of functions, write a long list of imports or find another library.
Finally, analysis based on node modules assumes a function-oriented or
object-based language, but ES6 is a class-based language: based on our
experience the majority of exports going forward will be classes.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140609/8893ea6b/attachment.html>

More information about the es-discuss mailing list