Rationale for dropping ModuleImport syntax?

[Matthew Robb]

I've been thinking about this thread a lot the last couple days. I started
out feeling defensive of the current proposal but I think I do agree that
the idea of live bound imports is neat it's also not something I'm asking
for or planning to use in the near term. I really just want single exports
and destructuring of single exports...

Is there a way to eventually spec the 'value as getter' concept separately?
On Jun 10, 2014 8:24 AM, "Forrest Norvell" <othiym23 at gmail.com> wrote:

>
> On Tue, Jun 10, 2014 at 5:19 AM, Domenic Denicola <
> domenic at domenicdenicola.com> wrote:
>
>> From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of
>> Marius Gundersen
>>
>> > I'd say we only support named exports, something like this:
>> https://gist.github.com/mariusGundersen/88a4c5690e08da0d07f6
>>
>> If you do that, the real-world consequences will be even worse. Nobody
>> (to a first approximation) will use ES6 modules at all, as they will be
>> entirely incompatible with how modules are used today by both AMD and
>> CommonJS communities.
>>
>
> This is my primary concern as well. I know from conversations with Node
> developers (some of whom are connected to the development of the platform
> itself) that many, if not most, of them are dubious about the benefits of
> the new module system. I tend to be pessimistic, so I also tend to write
> down my intuition somewhat, but based on the conversations I've had within
> the Node community, I would be surprised if a statistically meaningful
> number of the modules on npm end up being rewritten to use ES6 module
> syntax (once it's even available in V8). If you make changes that affect
> the usability of either single export or single import of multiple export,
> you're in effect making the headwinds that much stiffer. I think Domenic
> and Kevin's concerns about messing with a fragile consensus are entirely
> warranted.
>
> My broader concern is that it's very late in the specification process to
> be proposing these kinds of changes, and it feels like the proposals on the
> table violate the spirit of the design process that's been proposed for ES7
> and beyond. I know that ES6 is still governed by the old rules, but if the
> goal of the future process is to have the volume of changes to proposed
> features converge on zero as the feature moves through the process, that
> doesn't seem like it has to be something that blocks on the formal adoption
> of a new process.
>
> F
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140610/82e6e56f/attachment.html>