Rationale for dropping ModuleImport syntax?

[Brian Di Palma]

On Thu, Jun 12, 2014 at 6:37 PM, Chris Toshok <toshok at gmail.com> wrote:
> 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'`.
>

I can see that being a valid path for certain modules to take. I'm not
sure large utility packages will be as prevelant in future though.
Once we have a standard module system it seems just as likely that
these packages might break apart somewhat.
There seems no reason to load all of underscore into a module for just
one or two functions.

The underscore web page itself divides the functions http://underscorejs.org/

We should also be wary of building cases on code from Parsers, I
believe the unstructured switch statement was designed for parsers.
It didn't turn out to be an optimal design for routine programming though.

I was more wondering if there was anything preventing a module import
statement from being added later, if it was found to be a requirement.
I can't see any reason why it couldn't, that would also allow time for
bikeshedding the syntax.

>> 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.
>

The imperative code given as an alternative is ugly, it probably won't
gain many users.

> 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 like the idea but I can't imagine many people would welcome yet more
changes to ES modules.

>
> 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