第4章 模塊演義與Require.js

JavaScript最初并沒有提供模塊化規范，可能連它的設計者都沒有指望讓它承擔過重的任務，但隨著前端的發展，JavaScript逐漸承擔起完整應用的開發工作，這必然會帶來模塊劃分和管理的需求。JavaScript社區出現了很多模塊化解決方案，這讓許多非專業前端開發者感到很混亂。舊的模塊化解決方案都是利用JavaScript自身的特性模擬出來的，它們無一例外都有著奇怪的語法，且無法在瀏覽器環境中直接使用，更別提社區里先后出現的CMD、AMD、UMD等多種模塊化方案，想要分清楚真的很難。好不容易等到ES6標準提出解決方案，卻又在工程實踐中因為種種問題而未能統一實行，如果你查看過webpack的打包產物，就會發現其中內置了一個實現了CommonJS規范的簡易加載器，它可使打包產物運行在瀏覽器中，而開發過程中使用ES Module的語法（指通過import關鍵字來引入模塊，export關鍵字來導出模塊）僅僅是為了方便理解，對應的模塊會在webpack打包的過程中被轉換為CommonJS模塊。直到2021年，基于ES Module的構建工具才開始在開發環境中嶄露頭角，它借助跨語言的優勢將構建速度提升了幾十倍，不過要在生產環境中穩定使用還需要一些時間。目前，許多前端工程師對于模塊化的認知僅僅是“打包工具會處理好它們的”。

要想掌握模塊化的知識，需要明確的一個最重要的原則就是：“即使沒有模塊化，業務邏輯代碼也是能正常運行的”。在不同的模塊化標準中，我們用不同的外層代碼結構包裹著自己編寫的業務邏輯代碼，相信你也曾有過這樣的疑惑，明明是代碼在承載著業務邏輯，即使不用外層代碼結構來包裹，它也依然可以正常運行，模塊化相關的代碼并沒有增加任何業務邏輯，為什么還要畫蛇添足呢？你的疑惑是有道理的，但模塊化規范的出現，本身就是軟件工程的一種訴求，它的目的是提高工程層面的可維護性，并不會直接面向業務邏輯場景。本章就從前端開發領域最初面臨的問題開始，來看看對模塊化的訴求是如何產生的，再分別講述各種模塊化標準是如何處理這些訴求的，Require.js是AMD模塊化規范的實現，本章的最后將以它為例講解包模塊管理工具的用法和原理。