JavaScript – Modular
前言
我几乎闪过了那几年的 Modular 混乱时代.
CommonJS 火的时候, 我没有用 Node.js
AMD, CMD 火的时候, 我的项目还小, 加上用了 AngularJS 自带模块功能.
后来 UMD SystemJS 火了, 我在用 Angular 了, 从此开启 TypeScript 之路.
一直到最近想整理 TypeScript 笔记, 才顺便把历史补一补.
参考
掘金 – JS模块化方案详解(CommonJS、AMD、CMD、ESModule) (先看)
10分钟带你了解JavaScript模块化的前世今生! (必看)
知乎 – 2020年我们可以在Node中使用ES Modules了吗 (必看)
历史发展
JavaScript 语言设计的时候是没有 Modular 概念的. 因为也没有需求.
一直到 2009 年 Node.js 火了. JavaScript 要运用到后端场景, 这就必然需要改良语言了 (后端耶...超复杂的...) (这有点像现在的 C# 一直加入函数式特色, 就是为了要搞 Blazor 啊)
于是 Node.js 提出了 CommonJS, 一个 js file 表示 1 个模块, 通过 exports 和 require 关键字作为导出, 导入声明.
几年后, 前端需求越来越复杂, JavaScript 代码越来越多, 也需要模块化了. 但是 CommonJS 是按照后端需求设计的. 和前端水土不服丫.
所以 AMD 和 CMD 被提了出来.
AMD 的实现是 RequireJS, CMD 的实现是 Sea.js
后来打包工具出现了, 开发前端需要先用 Node.js 做打包, 最终输出 1 个 js file. 于是模块化的工作又交给了 Node.js
而且许多前端的 library 和后端的 library 是可以通用的, 但是模块管理却不一样... 这时代最混乱.
后来 UMD 出来了. 它的实现是 SystemJS. 它统一了 CommonJS, AMD, CMD 前后端模块规范写法, 通过 SystemJS 都可以导入导出
UMD 稳定了以后, ECMAScript 终于推出了 ES Module.
此后 JavaScript 语言终于是有了名正言顺的 Modular 方案.
而今天, 前端开发用 ES Module 就行了. 但是后端还有许多 CommonJS 的 Library 一时半会儿不可能全部迁移, 但也不必担心. 这些都交由 Webpack 之类的打包工具去搞就可以了.
像我一直受 AngularJS 和 Angular 保护. 从来就没有关心过这些 "底层" 实现.
总结
CommonJS 规范又称 CJS 是给 Node.js 用的 (.cjs)
AMD 规范的是现实 RequireJS 是给前端用的
CMD 规范的实现是 Sea.js 也是给前端用的 (类似 Vue 那样, 就是在某些基础上对某些场景做优化而诞生的)
UMD 规范统一了 CommonJS, AMD, CMD 规范, 它的实现是 SystemJS
ES Module 规范又称 ESM, 正统的 JavaScript Modular 规范. 游览器, Node.js 都支持了. (.mjs)
