自己的一些理解
#CommonJS
服务器端的 Node.js 规范,允许模块通过 require 方法来同步加载所要依赖的其他模块，然后通过 exports 或 module.exports 来导出需要暴露的接口。不适合在浏览器环境中，同步意味着阻塞加载，会造成浏览器假死；
#AMD
适合在浏览器环境中异步加载模块，在声明模块的时候指定所有的依赖 dependencies ，使用 CommonJS 浏览器端的一种妥协方案。
#EcmaScript6
新的 EcmaScript 标准； 编译时就能确定模块的依赖关系，以及输入和输出的变量。 CommonJS 和 AMD 模块，都只能在运行时确定这些东西。好多浏览器还是没有支持， 需要使用 babel 编译为 JavaScript 5 。

System.js 比较好的解决了各种模块、语言之间的混合开发

coffeescript 的一种叫法： JavaScript 的方言， 感觉好贴切。

AMD, CommonJS 都是模块化的规范, 这些都是在 ES6 之前的东西. 本质上没有什么不同, 语法而已, 建议使用 ES6 的语法.

我觉得楼主对 JavaScript 的模块还不够理解. 我有个工程 A, 引用了 npm 中安装的 B, 然后引用了自己以前写的 C 的部分功能. Webpack 从 A 开始打包, 它帮我自动引入了 B 和 C 的相关功能. 在 A 中这样引用就行:

import B from 'B'
import C from './C.js'

---

JavaScript 的一个特殊的地方就是有 "polyfill". 语言太灵活了, 你可以自己构建语法, 翻译到 JavaScript 就行. 方言这种说法也挺贴切, CoffeeScript 是方言, TypeScript 是方言, 可以说 ES6 也是方言. 只要每种方言不写在一个文件中, 就很好对接.

@iugo 非常感谢，您的指点； 可不可以这样理解， coffeescript 这些方言不要混写到同一个文件中； gulp 这类编译工具，将他们统一编译为.js 的普通话， 最后再由 webpack 把这些 js 的普通话组织压缩在一起。当然 webpack 自己可以进行编译工作。

@Yliuxx 可以这样理解. Webpack 是个打包器, 许多功能是一些 modules 帮着实现的, Sass 转 CSS, 热加载什么. 它就是个平台.

@iugo 太感谢了， 经过您的指导，重新梳理了下思路，现在又进一步理解。