如今模塊化的 JavaScript 的開發(fā)越來越火熱，無論是模塊加載器還是優(yōu)秀的 JavaScript 模塊，都是層出不窮。既然這么火，肯定是有存在的理由，肯定是解決了某些實際問題。很多沒接觸過模塊化 JavaScript 開發(fā)者不禁要問，我真的需要模塊化嗎，模塊化相比于傳統(tǒng)的模式有什么優(yōu)勢？

JavaScript 本身是沒有模塊化支持的，很多語言都有，就連CSS都有這樣的加載方式。

@import "fed.css";

雖然因為性能問題不推薦CSS這樣來進行加載，但這是一種模塊化的思想，這種思想對于 JavaScript 來說很有用。幸好JavaScript是一門靈活的語言，可以通過下面這段代碼來進行動態(tài)加載 JavaScript 文件。

var script = document.createElement( 'script' ), head = document.head;

script.src = 'http://example.com/test.js'; script.async = 'async'; head.insertBefore( script, head.firstChild );

傳統(tǒng)的加載方式必須在頁面中放置一個 script 標簽來進行加載。

<script type="text/javascript" src="http://example.com/test.js"></script>

更好的分離

那如果要加載多個就得放置多個 script 標簽，如果是加載模塊的話，拿 easy.js 來說，頁面中始終只要引用 easy.js 即可，這樣對于 HTML 和 JavaScript 分離很有好處，在某些場景下這個分離度很重要。

就拿我司的情況來說吧。后端的 view 層并不是由我們前端來開發(fā)的，項目上線的時候，前端只能更新 CSS 和 JS 文件，HTML 文件動不了。如果前端要在該頁面新增一個 JavaScript 文件的引用是很麻煩的，因為后端程序的更新都要嚴格按照流程來并有固定的更新時間，如果是用模塊加載的方式不用再理會后端的更新。當然，你也許會說，如果原頁面中已經有 JavaScript 文件，我直接在原文件中加代碼不就行了，那么接下來說說直接在原文件中新增代碼會碰到什么樣的問題。

更好的代碼組織方式

如果單個文件越來越大，維護起來出問題的幾率也會越來越大，一個人開發(fā)還好，如果是多人開發(fā)，不同的代碼風格，超多的業(yè)務邏輯混雜在一起，不要說維護了，光想想都蛋痛。模塊式的開發(fā)，一個文件就是一個模塊，控制了文件的粒度，每個模塊可以專注于一個功能。正所謂一個蘿卜一個坑，多人開發(fā)時，各自管好自己坑里的蘿卜就行了，這也正是 OOP 的思想。

按需加載

還是圍繞單個文件來說事，當文件大到一定的程度，性能問題也隨之而來了。合并文件是能減少請求，這是會帶來性能的提升，但是當文件大到一定的體積時，此時的下載時間可能并不會比多個小文件的下載時間更短。此時就需要權衡請求數(shù)和文件體積的關系了。

單文件還有一個問題，那就是緩存是否能充分的利用好。如果一個大體積的文件內包含了超多的業(yè)務邏輯和復雜的功能，而這個文件同時又被很多頁面引用到。比如在某頁面，實際只用到了該文件一個很少的功能，那么其他的代碼對于該頁面來說就是多余的，浪費了加載流量。你或許會說，這個文件雖然大，但是它第一次加載的時候就被緩存過了，盡管在某頁面只用到了極少部分的功能，但只要緩存過，加載還是挺快的。是的，如果情況有這么理想肯定是好事。但是，往往理想和現(xiàn)實都會有差距，如果產品的迭代更新太快，業(yè)務需求一天一個樣，那么該文件就會三天兩頭的更新，更新可能是一個很小的功能，但是這樣的更新對于刷新緩存的代價可是很大的。如果確實有這種情況，就說明這種設計確實是有問題。如果能合理的對文件進行模塊化的管理，那么可以盡量減少不必要的加載，盡量減少刷新大文件的緩存帶來的損失，這也需要權衡好，比如將很少更新的合并成一個文件，常更新的獨立成模塊。

避免命名沖突

JavaScript 本身是沒有命名空間的，為了避免命名沖突，經常會使用對象和閉包的辦法來避免。用對象僅僅是降低了沖突的概率而已，拿經常使用 jQuery 的開發(fā)來說，無論是往 $ 上擴展還是在 $.fn 上擴展，人多了難免會起沖突。或者用自定義的對象，搞個好幾層，不光是寫起來難記，這樣的調用也會在性能上打折扣的。模塊化就很好的解決了這個問題，在該模塊內的任何形式的命名都不會再和其他模塊有沖突，你想起啥名都行了。當然，你硬要在模塊內部給 window 上掛一堆東西，我也沒辦法。

既然每個模塊都是封閉式的，那么模塊之間如何通信呢？接口的設計那是必須的。很簡單，對于像 seajs 這種 CMD 規(guī)范的，需要使用自定義的關鍵字來向外部暴露一個接口。

define(function( require, exports ){ var hello = 'hello world'; // 向外部暴露該模塊的接口 exports.hello = hello; });

easy.js 遵循 AMD 規(guī)范，暴露接口更簡單，直接用 return 關鍵詞即可。

define( 'hello', function(){ var hello = 'hello world'; // 向外部暴露該模塊的接口 return hello; });

更好的依賴處理

傳統(tǒng)的開發(fā)模式，如果 B 文件要依賴 A 文件，那么必須在 B 文件前面用 script 的形式先加載好 A 文件。如果有一天，B 文件不再需要依賴 A 文件，或者要增加依賴文件 C，那么又回到了我說的第一個問題上。如果這個 B 文件被 N 個頁面在調用，而且頁面還跨業(yè)務站點，那改起來簡直就是噩夢啊。如果是用模塊化，只需要在模塊內部聲明好依賴就行了，增加刪除都直接修改模塊即可。調用的時候也不用管該模塊依賴了哪些其他模塊，放心的用就是了。

本文來自成都品牌網站建設網站設計公司-創(chuàng)新互聯(lián)

本文標題：模塊化相比于傳統(tǒng)的模式有什么優(yōu)勢？
網頁鏈接：http://aaarwkj.com/news47/326547.html

成都網站建設公司_創(chuàng)新互聯(lián)，為您提供動態(tài)網站、虛擬主機、ChatGPT、企業(yè)網站制作、軟件開發(fā)、網站營銷

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)