AMD modules can effectively only be consumed by a browser, or a browser-focused bundling tool, since AMD was designed for the "cascading waterfall" loading approach. Anecdotally, I see no new libraries being written in AMD format, and some that are written in AMD are looking at transitioning to ES6 modules.
CommonJS modules are intended for synchronous loading under Node, and tools like Webpack and Browserify can wrap them up to be used in a browser.
ES6 modules are designed to be statically analyzable, which is a key factor in "tree shaking" to drop unused code out of a generated bundle. However, the ES6 spec only defined the syntax for modules, not how they should be loaded. Major browsers have finally implemented native support for ES6 modules, but there's still a lot of complexity around how they're going to be implemented in Node [0].
There's also complexity around how lib authors publish packages to NPM. The most compatible approach is to author lib code as ES6 modules and whatever syntax additions you want, then compile it to CommonJS and ES5 before publishing. However, that loses out on any possible benefits from tree shaking. See this Twitter thread with discussion from Dan Abramov [1].
For more info on the history and differences between various JS module formats, see the "Javascript Module Formats" section of my React/Redux links list [2].
> There's also complexity around how lib authors publish packages to NPM. The most compatible approach is to author lib code as ES6 modules and whatever syntax additions you want, then compile it to CommonJS and ES5 before publishing.
There's also a growing trend among some major libraries to publish NPM packages only as ESM and use an shim like @std/esm to load them in Node:
>Anecdotally, I see no new libraries being written in AMD format, and some that are written in AMD are looking at transitioning to ES6 modules
Quite possibly because one of the biggest backers of the AMD format, Dojo* is now transitioning to ES6 modules.
*I really gotta hand it to those folks. They pioneer quite a bit of tech. Sometimes it sticks, sometimes it falls by the wayside, and sometimes it returns as someone else's "idea".
AMD modules can effectively only be consumed by a browser, or a browser-focused bundling tool, since AMD was designed for the "cascading waterfall" loading approach. Anecdotally, I see no new libraries being written in AMD format, and some that are written in AMD are looking at transitioning to ES6 modules.
CommonJS modules are intended for synchronous loading under Node, and tools like Webpack and Browserify can wrap them up to be used in a browser.
ES6 modules are designed to be statically analyzable, which is a key factor in "tree shaking" to drop unused code out of a generated bundle. However, the ES6 spec only defined the syntax for modules, not how they should be loaded. Major browsers have finally implemented native support for ES6 modules, but there's still a lot of complexity around how they're going to be implemented in Node [0].
There's also complexity around how lib authors publish packages to NPM. The most compatible approach is to author lib code as ES6 modules and whatever syntax additions you want, then compile it to CommonJS and ES5 before publishing. However, that loses out on any possible benefits from tree shaking. See this Twitter thread with discussion from Dan Abramov [1].
For more info on the history and differences between various JS module formats, see the "Javascript Module Formats" section of my React/Redux links list [2].
[0] https://medium.com/the-node-js-collection/the-current-state-...
[1] https://twitter.com/dan_abramov/status/938090483166924800
[2] https://github.com/markerikson/react-redux-links/blob/master...