Harmony modules feedback

Mark S. Miller erights at google.com
Mon Jan 16 08:55:10 PST 2012

On Mon, Jan 16, 2012 at 7:51 AM, Mariusz Nowak <
medikoo+mozilla.org at medikoo.com> wrote:

> rauschma wrote:
> >
> > For incrementally migrating old code bases, it would make a lot of sense
> > to allow ES.next modules to import AMDs and vice versa.
> >
> -1
> I'm not sure if I understood this correctly, but trying to support
> backwards
> what was never a standard is probably not good idea, and AMD didn't get
> that
> much momentum to make exception for that, for many it's still
> controversial.

While I agree that ES.next modules do not need to worry about AMD if it
does not establish itself as a widely used de facto standard, I think we
would all be better off if (the core subset of) AMD did become a wild
success and ES.next felt the need to figure out how to manage the

The reason being that currently, the only widespread practice for browser
programming is to do inter-module linkage by side effecting shared global
state, such as new shared global variables. ES.next modules do not and
probably cannot offer a smooth transition from this practice. It can at
best achieve an uneasy co-existence, which is the most any proposal has

As soon as ES.next modules becomes available in JS engines, server-side
programmers can start to use them. The situation is of course much less
happy in the browser. Even after all the browsers roll out ES.next, there
will be a long fade-out period when programmers will want to write most of
their browser-side code so that it continues to work on ES5 browsers (or
even ES3 browsers, depending on how the timing works out). While they could
use an ES.next to ES3-or-ES5 translator, experience shows that most will
continue to deploy code without such a translation step.

AMD is a simple elegant solution for doing inter-module linkage without
(much) global state. It works today across browsers, including ES3. We
should see if we can identify a translation between well chosen subsets of
AMD and ES.next modules. But even if no good automatic translation is
found, code written to AMD will be more easily ported to ES.next modules
that code written by current web practices.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120116/6d26c105/attachment.html>

More information about the es-discuss mailing list