javascript模塊化、模塊加載器初探

最多見網站的javascript架構多是這樣的：

• 一個底層框架文件，如jQuery
• 一個網站業務框架文件，包含整站公用業務模塊類(如彈框、ajax封裝等)
• 多個業務文件，包含每一個具體頁面有關係的業務代碼

　　爲了減小一個HTTP請求，咱們可能將底層框架文件和網站業務框架文件combo成一個文件，做爲一個公用文件引入到每一個須要使用javascript的頁面中，再在具體的頁面中引入和當前頁相關業務js文件。爲了減小頁面加載腳本阻塞現象，咱們還能夠將腳本文件放在html的body底部進行加載。

　　這看似是一個很好的javascript架構方案。每一個頁面最多引用兩個js文件，打開首頁後，後續頁面均可以使用緩存中的combo過的js。若是底層框架改動不太頻繁，那麼緩存在用戶瀏覽器中的combo過的框架文件可以使用較長的時間。

　　當網站使用過一段時間後，你可能就會發現一些問題出來了。　　

• combo過的框架文件過大。雖然可使用YUI Compressor或Google Clousure等第三方壓縮工具壓縮、啓用gzip、使用CDN等優化手段優化。但底層框架會隨着開源框架升級，公用模塊增多，致使combo後的框架文件愈來愈大。
• 業務框架改動頻繁，致使瀏覽器緩存做用減少。因爲業務的增長，可能公用的業務模塊愈來愈多，致使業務框架頻繁修改。代碼修改後，瀏覽器須要從新加載新的框架文件。
• 團隊開發問題。隨着團隊人數的增長，可能每一個人開發一個公用業務模塊，形成多人須要對同一個文件進行修改。若使用TFS這種獨佔式簽出的版本管理工具，會對團隊的開發效率形成必定影響。

　　咱們再看看使用模塊加載器、並對javascript進行過模塊化處理的網站的javascript架構：

• 一個模塊加載器文件。如loader.js
• 多個底層模塊(如selector、ua等)，多個業務模塊(如dialog、suggest等)
• 多個頁面相關的腳本調用文件

　　優勢體現出來了：

• 按需加載：只加載當前頁面須要的模塊和文件，不需加載任何多餘文件和代碼。大大縮減了代碼量
• 並行加載：不少loader提供了並行加載多個文件的功能，減小了代碼加載的時間，優勢能作到下載和執行相分離。
• 利於團隊開發：團隊中每一個人負責開發各自的模塊，之間互不影響。
• 最大限度的利用緩存：模塊顆粒化後，每次更新可能只是其中一個小模塊，其餘未更新的能夠利用瀏覽器中的緩存。

　　既然javascript模塊化、使用模塊加載器有這麼多的好處，那麼咱們須要付出哪些努力：

• 選用或實現loader
• 底層框架的模塊化：咱們須要將底層框架按照各自的只能分紅不一樣的模塊，分清楚之間的依賴關係
• 實現業務模塊：將原來的業務模塊按照loader約定的代碼方式進行修改，實現新的業務模塊按照loader的方式編寫。