模塊化相比于傳統的模式
發布時間：2025-06-26 點擊：7
如今模塊化的 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 個頁面在調用，而且頁面還跨業務站點，那改起來簡直就是噩夢啊。如果是用模塊化，只需要在模塊內部聲明好依賴就行了，增加刪除都直接修改模塊即可。調用的時候也不用管該模塊依賴了哪些其他模塊，放心的用就是了。
企業網站優化這樣做快速提升權重！
關于云原生安全，你得關注這些事！
一個優質的營銷網站具備哪些優勢?
企業不做企業網站會有損失嗎？
定制網站：定制站和傳統網站有哪些不同
在網站建設前這些網站設計誤區一定要避免掉，否則難上加難!
網站優化時怎樣維持網站的良性發展?
網站設計怎樣才能做到抓人眼球
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 個頁面在調用，而且頁面還跨業務站點，那改起來簡直就是噩夢啊。如果是用模塊化，只需要在模塊內部聲明好依賴就行了，增加刪除都直接修改模塊即可。調用的時候也不用管該模塊依賴了哪些其他模塊，放心的用就是了。
企業網站優化這樣做快速提升權重！
關于云原生安全，你得關注這些事！
一個優質的營銷網站具備哪些優勢?
企業不做企業網站會有損失嗎？
定制網站：定制站和傳統網站有哪些不同
在網站建設前這些網站設計誤區一定要避免掉，否則難上加難!
網站優化時怎樣維持網站的良性發展?
網站設計怎樣才能做到抓人眼球