ModuleImport

Kevin Smith zenparsing at gmail.com
Fri Jun 27 08:32:24 PDT 2014


> My opinion is that CommonJS and AMD work today and will continue to work
> into the future so we should optimize for the ideal "looking forward, not
> backward" case when adding to the language.
>

I think this statement points the way to something that we haven't yet
discussed.

A general question that we can apply to any language enhancement is:  does
this change merely satisfy existing users, or does this change carry the
potential to expand the user base?

I would say that "Node-module-sugar" would merely satisfy existing users,
but "real" modules have the capacity to expand the JS user base to into
segments that want static checking to be a part of their workflow.

So to me the path forward is clear:  we keep real modules, axe the default
feature, and take a temporary hit of dissatisfaction from existing users so
that we can expand the JS user base.

The overriding concern should be the long-term viability of JS.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140627/cc91ab92/attachment.html>


More information about the es-discuss mailing list