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

　　最常見網(wǎng)站的javascript架構可能是這樣的：

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

　　為了減少一個HTTP請求，我們可能將底層框架文件和網(wǎng)站業(yè)務框架文件combo成一個文件，作為一個公用文件引入到每個需要使用javascript的頁面中，再在具體的頁面中引入和當前頁相關業(yè)務js文件。為了減少頁面加載腳本阻塞現(xiàn)象，我們還可以將腳本文件放在html的body底部進行加載。

　　這看似是一個很好的javascript架構方案。每個頁面最多引用兩個js文件，打開首頁后，后續(xù)頁面都可以使用緩存中的combo過的js。如果底層框架改動不太頻繁，那么緩存在用戶瀏覽器中的combo過的框架文件能夠使用較長的時間。

　　當網(wǎng)站使用過一段時間后，你可能就會發(fā)現(xiàn)一些問題出來了。　　

• combo過的框架文件過大。雖然可以使用YUI Compressor或Google Clousure等第三方壓縮工具壓縮、啟用gzip、使用CDN等優(yōu)化手段優(yōu)化。但底層框架會隨著開源框架升級，公用模塊增多，導致combo后的框架文件越來越大。
• 業(yè)務框架改動頻繁，導致瀏覽器緩存作用減小。由于業(yè)務的增加，可能公用的業(yè)務模塊越來越多，導致業(yè)務框架頻繁修改。代碼修改后，瀏覽器需要重新加載新的框架文件。
• 團隊開發(fā)問題。隨著團隊人數(shù)的增加，可能每個人開發(fā)一個公用業(yè)務模塊，造成多人需要對同一個文件進行修改。若使用TFS這種獨占式簽出的版本管理工具，會對團隊的開發(fā)效率造成一定影響。

　　我們再看看使用模塊加載器、并對javascript進行過模塊化處理的網(wǎng)站的javascript架構：

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

　　優(yōu)點體現(xiàn)出來了：

• 按需加載：只加載當前頁面需要的模塊和文件，不需加載任何多余文件和代碼。大大縮減了代碼量
• 并行加載：很多l(xiāng)oader提供了并行加載多個文件的功能，減少了代碼加載的時間，優(yōu)點能做到下載和執(zhí)行相分離。
• 利于團隊開發(fā)：團隊中每個人負責開發(fā)各自的模塊，之間互不影響。
• 最大限度的利用緩存：模塊顆粒化后，每次更新可能只是其中一個小模塊，其他未更新的可以利用瀏覽器中的緩存。

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

• 選用或?qū)崿F(xiàn)loader
• 底層框架的模塊化：我們需要將底層框架按照各自的只能分成不同的模塊，分清楚之間的依賴關系
• 實現(xiàn)業(yè)務模塊：將原來的業(yè)務模塊按照loader約定的代碼方式進行修改，實現(xiàn)新的業(yè)務模塊按照loader的方式編寫。