Rationale for dropping ModuleImport syntax?

[Chris Toshok]

On Thu, Jun 12, 2014 at 3:46 AM, Brian Di Palma <offler at gmail.com> wrote:

> Is there anything preventing the addition of a "ModuleImport" like
> affordance at a later stage (e.g. ES7)?
>

ModuleImport is the only way (in syntax) to achieve CommonJS `require`
behavior on the consumer-side when a module author exclusively uses
multiple exports.

Its lack will force existing module maintainers to export as small a set as
possible - likely either a single identifier - so that they can service the
existing identifier-as-namespace convention CommonJS forces.

Given that there's no real syntactic difference between single identifier
export and default export, I would imagine default export would win since
then you get:  `import _ from 'underscore'` instead of import { _ } from
'underscore'`.

Related to some other comments made in this thread, I think static
> verification errors are a great idea.
> I'd also like to echo the comments that ES6 modules seem well
> designed, looking forward to native implementations.


I definitely agree.  I think the semantics and specification are awesome.
 And having syntax at all is *huge* for tooling and aot/static compilers.

The ModuleImport syntax can be bikeshedded until the cows come home.  It's
not important (to me).  What's important is that there is syntax to get at
its functionality, not imperative code.

IMO the only real issue is the tight coupling between syntax used to import
and syntax used to export.  Why as a module consumer should the module
author's choice dictate which syntax I'm forced to use?  And why as a
module author should the syntax my users want to use dictate how I have to
export my module?  If syntaxes were decoupled, ModuleImport could go away
and we wouldn't lose the functionality, it would simply be `import _ from
'underscore'`.

I don't think it's outlandish, the possibility that a large enough portion
of the community will decide on a single import syntax as "best", and
network effects will result in it going from "best" to "only".

-c
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140612/566b09f1/attachment.html>