ES 模組簡史

您可能在現代 JavaScript 開發中使用過 ES 模組，但您知道它們演變背後的歷史嗎？了解從早期 JavaScript 實踐到今天的模組系統的歷程將幫助您了解我們已經走了多遠以及為什麼 ES 模組改變了遊戲規則。

早期：JavaScript 的起源

時間是 1995 年，第一個網頁創建四年後。大多數網站都很簡單——帶有文字和最小互動性的靜態頁面。然而，開發人員很快就在尋找使網頁更具動態性的方法。

在這種環境下，Netscape（當時占主導地位的網頁瀏覽器）聘請了 Brendan Eich 來創建一種可以直接在瀏覽器中運行的腳本語言。這導致了 JavaScript 的誕生，這是一種簡單易懂的語言，特別是對於像網頁設計師這樣的非程式設計師來說。他做到了，在 10 天內完成了第一個版本。

最初，JavaScript 的目的是在網頁上新增小型的增強功能，例如表單驗證，而不需要將資料往返到伺服器。然而，隨著網站的互動性變得越來越強，JavaScript 很快就超越了其最初的用途。

全球範圍和早期解決方法

早期，所有 JavaScript 程式碼都位於全域範圍內。隨著越來越多的開發人員在同一頁上添加程式碼，名稱衝突的風險也隨之增加。如果多個腳本使用相同的變數或函數名稱，程式碼可能會以意想不到的方式中斷。

為了解決這個問題，開發人員採用命名約定來防止衝突。如果一段程式碼只運行一次，開發人員通常會將其包裝在 IIFE（立即呼叫函數表達式）中。這使得函數和變數的作用域保持在函數內，防止它們污染全域命名空間。

這在當時已經夠好了，因為大多數網站都是伺服器端渲染的，客戶端邏輯很少。

CommonJS：伺服器端模組

2008 年，Ryan Dahl 創建了 Node.js，這是一個用於構建伺服器端應用程式的 JavaScript 運行時。這開啟了一個全新的可能性世界，但缺乏模組系統意味著開發人員難以管理大型程式碼庫。

2009年，CommonJS被引進來解決伺服器端的這個問題。 CommonJS 模組系統可讓開發人員定義模組、公開功能以及導入其他模組。以下是其工作原理的範例：

使用 CommonJS，每個檔案都被視為自己的模組，並且使用 require 函數導入模組並使用 module.exports 匯出。

CommonJS 的一些主要功能包括：

• 需要模組時，檔案副檔名是可選的（例如 require('./math') 自動尋找 math.js）。

• 模組載入是同步的，這表示程式會等待模組載入後再繼續執行。

在文章後面我們將了解為什麼 Ryan Dahl 承認對這兩個設計決定感到遺憾。

AMD：優化瀏覽器

大約在同一時間，另一個名為AMD（非同步模組定義）的模組系統被開發出來。 CommonJS 主要專注於伺服器端 JavaScript，而 AMD 旨在處理瀏覽器中的客戶端 JavaScript。

AMD 的關鍵特性是它能夠非同步載入模組。這使得瀏覽器可以在任何給定時間僅載入頁面所需的 JavaScript，從而透過減少初始頁面載入時間來提高效能。它還解決了與依賴項解析相關的問題，確保模組僅在其依賴項完成載入後才會運行。

AMD 的優點包括：

• 按需載入較小的 JavaScript 檔案。
• 由於模組載入更加可預測，頁面載入錯誤更少。
• 透過非同步載入進行效能最佳化。

隨著 2010 年 npm（伺服器端 JavaScript 的套件管理器）的興起，跨瀏覽器和伺服器共享程式碼的需求變得顯而易見。 Browserify 是一個工具，它允許開發人員透過轉換程式碼以與瀏覽器環境相容來在瀏覽器中使用 CommonJS 模組。

UMD：兩全其美......有點

有 2 個競爭標準：CommonJS 和 AMD。需要一個可以在任何地方工作而無需建置步驟的單一模組系統。並於 2011 年引入了通用模組定義（UMD）。

UMD 結合了兩全其美，讓開發人員編寫可以在以下位置運行的模組：

• Node.js（使用 CommonJS）。
• 瀏覽器（使用 AMD）。
• 全域範圍（如果 CommonJS 和 AMD 都不存在）。

UMD 在庫作者中非常流行，Lodash、Underscore.js、Backbone.js 和 Moment.js 等著名函式庫都採用了它。然而，UMD 有一些顯著的缺點。它在解決相容性問題的同時，也帶來了管理兩個系統的複雜性，並且繼承了 AMD 和 CommonJS 的問題。

ES 模組：終極模組標準

2015 年，ES 模組 (ESM) 作為 ECMAScript 標準的一部分被引入，最終為 JavaScript 提供了原生模組系統。到 2017 年，所有主流瀏覽器都支援 ES 模組，2020 年，Node.js 也加入了支援。

讓我們看看為什麼 ES 模組是最好的：

1. 方便的語法

以下UMD代碼：

現在可以簡化為：

公平地說，沒有人真正這樣寫 UMD。他們使用 umdify 等工具來產生該程式碼。但透過內建 ES 模組，我們可以跳過建置步驟並獲得更小的套件大小。

2.更好的優化

ES 模組是靜態的，這意味著工具可以在編譯時分析程式碼結構，以確定哪些程式碼正在使用，哪些沒有。這允許進行樹搖動，即從最終套件中刪除未使用的程式碼。

由於 CommonJS 和 AMD 模組是動態的（在運行時評估），因此這些系統的 Tree Shaking 效率要低得多，通常會產生更大的套件。

3.更顯式的程式碼

使用 CommonJS 匯入模組時，指定檔案副檔名是可選的。

但是數學到底指的是什麼？它是 JavaScript 檔案嗎？ JSON 檔案？數學目錄中的index.js 檔案？

當使用 ES Lint、Typescript 或 Prettier 等靜態分析工具時，每個需求都變成了猜謎遊戲。
是 math.js 嗎？
是 math.jsx 嗎？
是 math.cjs 嗎？
是 math.mjs 嗎？
是 math.ts 嗎？
是 math.tsx 嗎？
是 math.mts 嗎？
是 math.cts 嗎？
是 math/index.js 嗎？
是 math/index.jsx 嗎？

你明白了。

讀取文件的成本很高。它的性能比從記憶體中讀取要低得多。導入 math/index.js 會導致 9 次 IO 操作，而不是 1 次！這種猜謎遊戲正在減慢我們的工具速度並損害開發人員的體驗。

在 ES 模組中，我們透過強製檔案副檔名來避免這種混亂。

4. 非同步加載

與 CommonJS 同步載入模組（阻塞整個進程直到模組載入）不同，ES 模組是非同步的。這允許 JavaScript 在後台載入模組時繼續執行，從而提高效能 - 特別是在 Node.js 這樣的環境中。

遷移挑戰：為什麼花了這麼長時間

儘管有明顯的好處，但採用 ES 模組並不是一件簡單的任務。這就是過渡花了這麼長時間的原因：

1. 昂貴的遷移

從 CommonJS 切換到 ES 模組並不是一個簡單的改變，尤其是對於大型專案。語法差異加上對工具支援的需求，使得遷移變得非常困難。

2. 缺乏 Node.js 支持

node.js花了5年時間才完全支援ES模組。在此期間，開發人員必須保持與 CommonJS（在伺服器上）和 ES 模組（在瀏覽器上）的兼容性。這種雙重支持在生態系統中造成了許多摩擦。

3、相容性問題

即使 Node.js 新增了對 ES 模組的支持，CommonJS 模組也無法載入 ES 模組。雖然 ES 模組可以載入 CommonJS 模組，但這兩個系統無法完全互通，這給必須支援這兩個系統的套件作者帶來了額外的麻煩。

未來：ES 模組將繼續存在

JavaScript 模組的未來是光明的，以下是一些關鍵的發展，將使 ES 模組成為未來的主導系統：

1.Node.js 23

在 Node.js 23 中，我們終於能夠從 CommonJS 載入 ES 模組。
有一個小警告：使用頂級await的ES模組不能導入到CommonJS中，因為await只能在非同步函數中使用，而CommonJS是同步的。

2.JSR（JavaScript註冊表）

一個與 npm 競爭的新 javascript 套件註冊表。它比 npm 有很多優點，我在這裡不再贅述。但有趣的是你只能上傳 ES 模組包。無需支援舊標準。

結論

從全域範圍 hack 到現代 ES 模組的旅程改變了我們建構 JavaScript 的方式。經過多年對 CommonJS、AMD 和 UMD 的試驗，ES 模組已成為明確的標準，提供更簡單的語法、更好的優化和更高的性能。

雖然遷移到 ES 模組具有挑戰性，特別是在 Node.js 支援和生態系統相容性方面，但好處是不可否認的。隨著 Node.js 23 改進互通性以及 JSR 等新工具促進統一模組系統，ES 模組將成為 JavaScript 的預設模組。

隨著我們繼續擁抱 ES 模組，我們可以期待更乾淨、更快、更可維護的程式碼，標誌著 JavaScript 開發模組化的新時代。

以上是ES 模組簡史的詳細內容。更多資訊請關注PHP中文網其他相關文章！