1 引言

如今，Javascript 模塊化規范非常方便、自然，但這個新規范僅執行了2年，就在 4 年前，js 的模塊化還停留在運行時支持，10 年前，通過后端模版定義、注釋定義模塊依賴。對經歷過來的人來說，歷史的模塊化方式還停留在腦海中，反而新上手的同學會更快接受現代的模塊化規范。

但為什么要了解 Javascript 模塊化發展的歷史呢？因為凡事都有兩面性，了解 Javascript 模塊化規范，有利于我們思考出更好的模塊化方案，縱觀歷史，從 1999 年開始，模塊化方案最多維持兩年，就出現了新的替代方案，比原有的模塊化更清晰、強壯，我們不能被現代模塊化方式限制住思維，因為現在的 ES2015 模塊化方案距離發布也僅僅過了兩年。

2 內容概要

直接定義依賴 (1999): 由于當時 js 文件非常簡單，模塊化方式非常簡單粗暴 —— 通過全局方法定義、引用模塊。這種定義方式與現在的 commonjs 非常神似，區別是 commonjs 以文件作為模塊，而這種方法可以在任何文件中定義模塊，模塊不與文件關聯。

閉包模塊化模式 (2003): 用閉包方式解決了變量污染問題，閉包內返回模塊對象，只需對外暴露一個全局變量。

模版依賴定義 (2006): 這時候開始流行后端模版語法，通過后端語法聚合 js 文件，從而實現依賴加載，說實話，現在 go 語言等模版語法也很流行這種方式，寫后端代碼的時候不覺得，回頭看看，還是掛在可維護性上。

注釋依賴定義 (2006): 幾乎和模版依賴定義同時出現，與 1999 年方案不同的，不僅僅是模塊定義方式，而是終于以文件為單位定義模塊了，通過 lazyjs 加載文件，同時讀取文件注釋，繼續遞歸加載剩下的文件。

外部依賴定義 (2007): 這種定義方式在 cocos2d-js 開發中普遍使用，其核心思想是將依賴抽出單獨文件定義，這種方式不利于項目管理，畢竟依賴抽到代碼之外，我是不是得兩頭找呢？所以才有通過 webpack 打包為一個文件的方式暴力替換為 commonjs 的方式出現。

Sandbox模式 (2009): 這種模塊化方式很簡單，暴力，將所有模塊塞到一個 sanbox 變量中，硬傷是無法解決明明沖突問題，畢竟都塞到一個 sandbox 對象里，而 Sandbox 對象也需要定義在全局，存在被覆蓋的風險。模塊化需要保證全局變量盡量干凈，目前為止的模塊化方案都沒有很好的做到這一點。

依賴注入 (2009): 就是大家熟知的 angular1.0，依賴注入的思想現在已廣泛運用在 react、vue 等流行框架中。但依賴注入和解決模塊化問題還差得遠。

CommonJS (2009): 真正解決模塊化問題，從 node 端逐漸發力到前端，前端需要使用構建工具模擬。

Amd (2009): 都是同一時期的產物，這個方案主要解決前端動態加載依賴，相比 commonJs，體積更小，按需加載。

Umd (2011): 兼容了 CommonJS 與 Amd，其核心思想是，如果在 commonjs 環境(存在 module.exports，不存在 define)，將函數執行結果交給 module.exports 實現 Commonjs，否則用 Amd 環境的 define，實現 Amd。

Labeled Modules (2012): 和 Commonjs 很像了，沒什么硬傷，但生不逢時，碰上 Commonjs 與 Amd，那只有被人遺忘的份了。

YModules (2013): 既然都出了 Commonjs Amd，文章還列出了此方案，一定有其獨到之處。其核心思想在于使用 provide 取代 return，可以控制模塊結束時機，處理異步結果；拿到第二個參數 module，修改其他模塊的定義(雖然很有拓展性，但用在項目里是個攪屎棍)。

ES2015 Modules (2015): 就是我們現在的模塊化方案，還沒有被瀏覽器實現，大部分項目已通過 babel 或 typescript 提前體驗。

3 精讀

從語言層面到文件層面的模塊化

從 1999 年開始，模塊化探索都是基于語言層面的優化，真正的革命從 2009 年 CommonJS 的引入開始，前端開始大量使用預編譯。

這篇文章所提供的模塊化歷史的方案都是邏輯模塊化，從 CommonJS 方案開始前端把服務端的解決方案搬過來之后，算是看到標準物理與邏輯統一的模塊化。但之后前端工程不得不引入模塊化構建這一步。正是這一步給前端開發無疑帶來了諸多的不便，尤其是現在我們開發過程中經常為了優化這個工具帶了很多額外的成本。

從 CommonJS 之前其實都只是封裝，并沒有一套模塊化規范，這個就有些像類與包的概念。我在10年左右用的最多的還是 YUI2，YUI2 是用 namespace 來做模塊化的，但有很多問題沒有解決，比如多版本共存，因此后來 YUI3 出來了。

YUI().use('node', 'event', function (Y) { // The Node and Event modules are loaded and ready to use. // Your code goes here!});

YUI3 的 sandbox 像極了差不多同時出現的 AMD 規范，但早期 yahoo 在前端圈的影響力還是很大的，而 requirejs 到 2011 年才誕生，因此圈子不是用著 YUI 要不就自己封裝一套 sandbox，內部使用 jQuery。

為什么模塊化方案這么晚才成型，可能早期應用的復雜度都在后端，前端都是非常簡單邏輯。后來 Ajax 火了之后，web app 概念的開始流行，前端的復雜度也呈指數級上漲，到今天幾乎和后端接近一個量級。工程發展到一定階段，要出現的必然會出現。

前端三劍客的模塊化展望

從 js 模塊化發展史，我們還看到了 css html 模塊化方面的嚴重落后，如今依賴編譯工具的模塊化增強在未來會被標準所替代。

原生支持的模塊化，解決 html 與 css 模塊化問題正是以后的方向。

再回到 JS 模塊化這個主題，開頭也說到是為了構建 scope，實則提供了業務規范標準的輸入輸出的方式。但文章中的 JS 的模塊化還不等于前端工程的模塊化，Web 界面是由 HTML、CSS 和 JS 三種語言實現，不論是 CommonJS 還是 AMD 包括之后的方案都無法解決 CSS 與 HTML 模塊化的問題。

對于 CSS 本身它就是 global scope，因此開發樣式可以說是喜憂參半。近幾年也涌現把 HTML、CSS 和 JS 合并作模塊化的方案，其中 react/css-modules 和 vue 都為人熟知。當然，這一點還是非常依賴于 webpack/rollup 等構建工具，讓我們意識到在 browser 端還有很多本質的問題需要推進。

對于 css 模塊化，目前不依賴預編譯的方式是 styled-component，通過 js 動態創建 class。而目前 css 也引入了與 js 通信的機制 與 原生變量支持。未來 css 模塊化也很可能是運行時的，所以目前比較看好 styled-component 的方向。

對于 html 模塊化，小尤最近爆出與 chrome 小組調研 html Modules，如果 html 得到了瀏覽器，編輯器的模塊化支持，未來可能會取代 jsx 成為最強大的模塊化、模板語言。

對于 js 模塊化，最近出現的

總結

以上是生活随笔為你收集整理的js define函数_聊聊JS模块化发展历程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。