如今模塊化的 JavaScript 的開發越來越火熱，無論是模塊加載器還是優秀的 JavaScript 模塊，都是層出不窮。既然這麼火，肯定是有存在的理由，肯定是解決了某些實際問題。很多沒接觸過模塊化 JavaScript 開發者不禁要問，我真的需要模塊化嗎，模塊化相比於傳統的模式有什麼優勢？
JavaScript 本身是沒有模塊化支持的，很多語言多有，就連CSS都有這樣的加載方式。
@import "fed.css";
雖然因為性能問題不推薦CSS這樣來進行加載，但這是一種模塊化的思想，這種思想對於 JavaScript 來說很有用。幸好JavaScript是一門靈活的語言，可以通過下面這段代碼來進行動態加載 JavaScript 文件。
var script = document.createElement( 'script' ),
head = document.head;script.src = 'http://example.com/test.js';
script.async = 'async';
head.insertBefore( script, head.firstChild );
傳統的加載方式必須在頁面中放置一個 script 標簽來進行加載。
<script type="text/javascript" src="http://example.com/test.js"></script>
更好的分離
那如果要加載多個就得放置多個 script 標簽，如果是加載模塊的話，拿 easy.js 來說，頁面中始終只要引用 easy.js 即可，這樣對於 HTML 和 JavaScript 分離很有好處，在某些場景下這個分離度很重要。
就拿我司的情況來說吧。後端的 view 層並不是由我們前端來開發的，項目上線的時候，前端只能更新 CSS 和 JS 文件，HTML 文件動不了。如果前端要在該頁面新增一個 JavaScript 文件的引用是很麻煩的，因為後端程序的更新都要嚴格按照流程來並有固定的更新時間，如果是用模塊加載的方式不用再理會後端的更新。當然，你也許會說，如果原頁面中已經有 JavaScript 文件，我直接在原文件中加代碼不就行了，那麼接下來說說直接在原文件中新增代碼會碰到什麼樣的問題。
更好的代碼組織方式
如果單個文件越來越大，維護起來出問題的幾率也會越來越大，一個人開發還好，如果是多人開發，不同的代碼風格，超多的業務邏輯混雜在一起，不要說維護了，光想想都蛋痛。模塊式的開發，一個文件就是一個模塊，控制了文件的粒度，每個模塊可以專注於一個功能。正所謂一個蘿卜一個坑，多人開發時，各自管好自己坑裡的蘿卜就行了，這也正是 OOP 的思想。
按需加載
還是圍繞單個文件來說事，當文件大到一定的程度，性能問題也隨之而來了。合並文件是能減少請求，這是會帶來性能的提升，但是當文件大到一定的體積時，此時的下載時間可能並不會比多個小文件的下載時間更短。此時就需要權衡請求數和文件體積的關系了。
單文件還有一個問題，那就是緩存是否能充分的利用好。如果一個大體積的文件內包含了超多的業務邏輯和復雜的功能，而這個文件同時又被很多頁面引用到。比如在某頁面，實際只用到了該文件一個很少的功能，那麼其他的代碼對於該頁面來說就是多余的，浪費了加載流量。你或許會說，這個文件雖然大，但是它第一次加載的時候就被緩存過了，盡管在某頁面只用到了極少部分的功能，但只要緩存過，加載還是挺快的。是的，如果情況有這麼理想肯定是好事。但是，往往理想和現實都會有差距，如果產品的迭代更新太快，業務需求一天一個樣，那麼該文件就會三天兩頭的更新，更新可能是一個很小的功能，但是這樣的更新對於刷新緩存的代價可是很大的。如果確實有這種情況，就說明這種設計確實是有問題。如果能合理的對文件進行模塊化的管理，那麼可以盡量減少不必要的加載，盡量減少刷新大文件的緩存帶來的損失，這也需要權衡好，比如將很少更新的合並成一個文件，常更新的獨立成模塊。
避免命名沖突
JavaScript 本身是沒有命名空間的，為了避免命名沖突，經常會使用對象和閉包的辦法來避免。用對象僅僅是降低了沖突的概率而已，拿經常使用 jQuery 的開發來說，無論是往 $ 上擴展還是在 $.fn 上擴展，人多了難免會起沖突。或者用自定義的對象，搞個好幾層，不光是寫起來難記，這樣的調用也會在性能上打折扣的。模塊化就很好的解決了這個問題，在該模塊內的任何形式的命名都不會再和其他模塊有沖突，你想起啥名都行了。當然，你硬要在模塊內部給 window 上掛一堆東西，我也沒辦法。
既然每個模塊都是封閉式的，那麼模塊之間如何通信呢？接口的設計那是必須的。很簡單，對於像 seajs 這種 CMD 規范的，需要使用自定義的關鍵字來向外部暴露一個接口。
define(function( require, exports ){
var hello = 'hello world';
// 向外部暴露該模塊的接口
exports.hello = hello;
});
easy.js 遵循 AMD 規范，暴露接口更簡單，直接用 return 關鍵詞即可。
define( 'hello', function(){
var hello = 'hello world';
// 向外部暴露該模塊的接口
return hello;
});
更好的依賴處理
傳統的開發模式，如果 B 文件要依賴 A 文件，那麼必須在 B 文件前面用 script 的形式先加載好 A 文件。如果有一天，B 文件不再需要依賴 A 文件，或者要增加依賴文件 C，那麼又回到了我說的第一個問題上。如果這個 B 文件被 N 個頁面在調用，而且頁面還跨業務站點，那改起來簡直就是噩夢啊。如果是用模塊化，只需要在模塊內部聲明好依賴就行了，增加刪除都直接修改模塊即可。調用的時候也不用管該模塊依賴了哪些其他模塊，放心的用就是了。
好了，講了這麼多，如果你還是覺得無動於衷，要麼是你接觸到的項目較小，還沒復雜到這個程度，要麼就是我的表達能力有問題。如果你覺得還有什麼需要補充的，歡迎在下面留言。
文章來源：雨夜帶刀‘s Blog，轉載請注明出處。
