WARNING: This server is unstable and will be retired in the next days.
If you want to keep this forum available, please request immediately a migration
on the Nabble Support forum.
Forums that don't receive any migration request will be deleted forever.
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.