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.
> For incrementally migrating old code bases, it would make a lot of sense
> to allow ES.next modules to import AMDs and vice versa.
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 transition.
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 offered.
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.