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