模塊化（CommonJs、AMD、CMD、UMD）發展歷史與優缺點

時間 2019-11-13

標籤模塊化 commonjs amd cmd umd 發展歷史優缺點简体版

原文原文鏈接

全文主要整理自摘自《Webpack中文指南》（好文，建議直接去看，如下僅對該系列文章中的《歷史發展》篇幅進行備份——也整理了點其餘內容）css

模塊化

模塊化是老生常談了，這裏不作闡述。html

模塊化管理須要具有：前端

1. 定義封裝的模塊。node

2. 定義新模塊對其餘模塊的依賴。jquery

3. 可對其餘模塊的引入支持。webpack

要通用，則必需要有規範化，所以一系列的標準應運而生。git

現狀

伴隨着移動互聯的大潮，當今愈來愈多的網站已經從網頁模式進化到了 Webapp 模式。它們運行在現代的高級瀏覽器裏，使用 HTML五、 CSS三、 ES6 等更新的技術來開發豐富的功能，網頁已經不只僅是完成瀏覽的基本需求，而且webapp一般是一個單頁面應用，每個視圖經過異步的方式加載，這致使頁面初始化和使用過程當中會加載愈來愈多的 JavaScript 代碼，這給前端開發的流程和資源組織帶來了巨大的挑戰。es6

前端開發和其餘開發工做的主要區別，首先是前端是基於多語言、多層次的編碼和組織工做，其次前端產品的交付是基於瀏覽器，這些資源是經過增量加載的方式運行到瀏覽器端，如何在開發環境組織好這些碎片化的代碼和資源，而且保證他們在瀏覽器端快速、優雅的加載和更新，就須要一個模塊化系統，這個理想中的模塊化系統是前端工程師多年來一直探索的難題。github

模塊系統的演進

模塊系統主要解決模塊的定義、依賴和導出，先來看看已經存在的模塊系統。web

<script>標籤

<script src="module1.js"></script> <script src="module2.js"></script> <script src="libraryA.js"></script> <script src="module3.js"></script>

這是最原始的 JavaScript 文件加載方式，若是把每個文件看作是一個模塊，那麼他們的接口一般是暴露在全局做用域下，也就是定義在 window 對象中，不一樣模塊的接口調用都是一個做用域中，一些複雜的框架，會使用命名空間的概念來組織這些模塊的接口，典型的例子如 YUI 庫。

這種原始的加載方式暴露了一些顯而易見的弊端：

全局做用域下容易形成變量衝突
文件只能按照 <script> 的書寫順序進行加載
開發人員必須主觀解決模塊和代碼庫的依賴關係
在大型項目中各類資源難以管理，長期積累的問題致使代碼庫混亂不堪

CommonJS

歷史

　　2009年1月，Mozilla 的工程師 Kevin Dangoor 建立了這個項目，當時的名字是 ServerJS。其是以在瀏覽器環境以外構建 JavaScript 生態系統爲目標而產生的項目，好比在服務器和桌面環境中。

　　2009年8月，這個項目更名爲 CommonJS，以顯示其 API 的更普遍實用性。

　　2013年5月，Node.js 的包管理器 NPM 的做者 Isaac Z. Schlueter 說 CommonJS 已通過時，Node.js 的內核開發者已經廢棄了該規範。

定義

　　服務器端的 Node.js 遵循 CommonJS規範，該規範的核心思想是容許模塊經過 require 方法來同步加載所要依賴的其餘模塊，而後經過 exports 或 module.exports 來導出須要暴露的接口。

　　require("module"); 　　require("../file.js"); 　　exports.doStuff = function() {}; 　　module.exports = someValue;

優勢：

服務器端模塊便於重用
NPM 中已經有將近20萬個可使用模塊包
簡單並容易使用

缺點：

同步的模塊加載方式不適合在瀏覽器環境中，同步意味着阻塞加載，瀏覽器資源是異步加載的
不能非阻塞的並行加載多個模塊

實現：

服務器端的 Node.js
Browserify，瀏覽器端的 CommonJS 實現，可使用 NPM 的模塊，可是編譯打包後的文件體積可能很大
modules-webmake，相似Browserify，還不如 Browserify 靈活
wreq，Browserify 的前身

AMD

AMD（異步模塊定義）是爲瀏覽器環境設計的，由於 CommonJS 模塊系統是同步加載的，當前瀏覽器環境尚未準備好同步加載模塊的條件。

AMD 定義了一套 JavaScript 模塊依賴異步加載標準，來解決同步加載的問題。

Asynchronous Module Definition 規範其實只有一個主要接口 define(id?, dependencies?, factory)，它要在聲明模塊的時候指定全部的依賴 dependencies，而且還要當作形參傳到 factory 中，對於依賴的模塊提早執行，依賴前置。

define("module", ["dep1", "dep2"], function(d1, d2) { return someExportedValue; }); require(["module", "../file"], function(module, file) { /* ... */ });

優勢：

適合在瀏覽器環境中異步加載模塊
能夠並行加載多個模塊

缺點：

提升了開發成本，代碼的閱讀和書寫比較困難，模塊定義方式的語義不暢
不符合通用的模塊化思惟方式，是一種妥協的實現

實現：

CMD

Common Module Definition 規範和 AMD 很類似，儘可能保持簡單，並與 CommonJS 和 Node.js 的 Modules 規範保持了很大的兼容性。

define(function(require, exports, module) { var $ = require('jquery'); var Spinning = require('./spinning'); exports.doSomething = ... module.exports = ... })

優勢：

依賴就近，延遲執行
能夠很容易在 Node.js 中運行

缺點：

依賴 SPM 打包，模塊的加載邏輯偏重

實現：

UMD

Universal Module Definition 規範相似於兼容 CommonJS 和 AMD 的語法糖，是模塊定義的跨平臺解決方案。

ES6 模塊

EcmaScript6 標準增長了 JavaScript 語言層面的模塊體系定義。ES6 模塊的設計思想，是儘可能的靜態化，使得編譯時就能肯定模塊的依賴關係，以及輸入和輸出的變量。CommonJS 和 AMD 模塊，都只能在運行時肯定這些東西。

import "jquery"; export function doStuff() {} module "localModule" {}

優勢：

容易進行靜態分析
面向將來的 EcmaScript 標準

缺點：

原生瀏覽器端尚未實現該標準
全新的命令字，新版的 Node.js才支持

實現：

Babel

指望的模塊系統

能夠兼容多種模塊風格，儘可能能夠利用已有的代碼，不只僅只是 JavaScript 模塊化，還有 CSS、圖片、字體等資源也須要模塊化。

前端模塊加載

前端模塊要在客戶端中執行，因此他們須要增量加載到瀏覽器中。

模塊的加載和傳輸，咱們首先能想到兩種極端的方式，一種是每一個模塊文件都單獨請求，另外一種是把全部模塊打包成一個文件而後只請求一次。顯而易見，每一個模塊都發起單獨的請求形成了請求次數過多，致使應用啓動速度慢；一次請求加載全部模塊致使流量浪費、初始化過程慢。這兩種方式都不是好的解決方案，它們過於簡單粗暴。

分塊傳輸，按需進行懶加載，在實際用到某些模塊的時候再增量更新，纔是較爲合理的模塊加載方案。

要實現模塊的按需加載，就須要一個對整個代碼庫中的模塊進行靜態分析、編譯打包的過程。

全部資源都是模塊

在上面的分析過程當中，咱們提到的模塊僅僅是指JavaScript模塊文件。然而，在前端開發過程當中還涉及到樣式、圖片、字體、HTML 模板等等衆多的資源。這些資源還會以各類方言的形式存在，好比 coffeescript、 less、 sass、衆多的模板庫、多語言系統（i18n）等等。

若是他們均可以視做模塊，而且均可以經過require的方式來加載，將帶來優雅的開發體驗，好比：

require("./style.css"); require("./style.less"); require("./template.jade"); require("./image.png");

那麼如何作到讓 require 能加載各類資源呢？

靜態分析

在編譯的時候，要對整個代碼進行靜態分析，分析出各個模塊的類型和它們依賴關係，而後將不一樣類型的模塊提交給適配的加載器來處理。好比一個用 LESS 寫的樣式模塊，能夠先用 LESS 加載器將它轉成一個CSS 模塊，在經過 CSS 模塊把他插入到頁面的 <style> 標籤中執行。Webpack 就是在這樣的需求中應運而生。

同時，爲了能利用已經存在的各類框架、庫和已經寫好的文件，咱們還須要一個模塊加載的兼容策略，來避免重寫全部的模塊。

那麼接下來，讓咱們開始 Webpack 的神奇之旅吧。