Harmony modules feedback

Axel Rauschmayer axel at rauschma.de
Mon Jan 16 10:02:55 PST 2012

> 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 transition.

From where I’m standing, AMD is already a standard in browser space. The only negative reaction I have seen is by Node.js developers – their reasons make sense from a server-centric viewpoint, but (IMHO) less if you are considering the bigger picture of using the same language for client and server. AMD’s greatest advantage is that its core is very simple and that it lends itself to asynchronous loading (which is a must for browsers).

> 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 than code written by current web practices.


Dr. Axel Rauschmayer
axel at rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

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

More information about the es-discuss mailing list