最常見網站的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的方式編寫。
