On Tue, Jun 10, 2014 at 5:19 AM, Domenic Denicola < [email protected]> wrote:
> From: es-discuss [mailto:[email protected]] 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 [email protected] https://mail.mozilla.org/listinfo/es-discuss
