Rationale for dropping ModuleImport syntax?
matthewwrobb at gmail.com
Tue Jun 10 08:47:54 PDT 2014
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:
>> 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
> 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.
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss