amd
、commonJS
、es6
、coffeescript
对比分析;比如: amd
、commonJS
使用require
; es6
中使用import
进行module
引入,各有什么不同;npm
安装对应的js module
之后, 怎么加载使用,怎么使用脚手架工具(module handler
)将他们打包为普通的js
,提供给浏览器使用,提供给其他人调用。module handler
), 将coffeescript
写的代码和es6
进行对接; 1
Yliuxx OP 自己的一些理解
#CommonJS 服务器端的 Node.js 规范,允许模块通过 require 方法来同步加载所要依赖的其他模块,然后通过 exports 或 module.exports 来导出需要暴露的接口。不适合在浏览器环境中,同步意味着阻塞加载,会造成浏览器假死; #AMD 适合在浏览器环境中异步加载模块,在声明模块的时候指定所有的依赖 dependencies ,使用 CommonJS 浏览器端的一种妥协方案。 #EcmaScript6 新的 EcmaScript 标准; 编译时就能确定模块的依赖关系,以及输入和输出的变量。 CommonJS 和 AMD 模块,都只能在运行时确定这些东西。好多浏览器还是没有支持, 需要使用 babel 编译为 JavaScript 5 。 |
2
learnshare 2016-04-14 15:55:28 +08:00 1
System.js 比较好的解决了各种模块、语言之间的混合开发
|
3
Yliuxx OP coffeescript 的一种叫法: JavaScript 的方言, 感觉好贴切。
|
4
iugo 2016-04-14 17:31:27 +08:00 1
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 也是方言. 只要每种方言不写在一个文件中, 就很好对接. |
5
Yliuxx OP @iugo 非常感谢,您的指点; 可不可以这样理解, coffeescript 这些方言不要混写到同一个文件中; gulp 这类编译工具,将他们统一编译为.js 的普通话, 最后再由 webpack 把这些 js 的普通话组织压缩在一起。当然 webpack 自己可以进行编译工作。
|