最近在思考前端js文件該如何合并,當(dāng)然不包括不能合并文件,而是我們能合并的文件,想了想應(yīng)該也只有三種方式。
三個(gè)方式如下:
1. 一個(gè)大文件,所有js合并成一個(gè)大文件,所有頁面都引用它。
2. 各個(gè)頁面大文件,各自頁面合并生成自己所需js的大文件。
3. 合并多個(gè)共用大文件,根據(jù)實(shí)踐情況合并出多個(gè)共用js文件,每個(gè)頁面引用多個(gè)共用大文件。
另外在我看來,合并有兩個(gè)目的:
1. 為了減少請(qǐng)求數(shù)。
2. 代碼安全考慮(文件分得越多,越容易被人看清)。
PS:注意我說的不是壓縮混淆,只是合并
1. 一個(gè)大文件
這種方式就是不管三七二十一,所有js合并成一個(gè)大文件,所有頁面都引用它,即使某些代碼可能不會(huì)用到。
優(yōu)點(diǎn):
(1). 合并簡(jiǎn)單,使用也簡(jiǎn)單。
(2). 其他頁面可利用緩存優(yōu)化加載。
缺點(diǎn):
(1). 頁面可能會(huì)加載到本頁面不使用的代碼。
不適用場(chǎng)景:
(1). 這種方式肯定不適用于大型的Web應(yīng)用,且不論單文件代碼量,業(yè)務(wù)的復(fù)雜性也不允許我們這樣干(我沒見過那個(gè)網(wǎng)站這樣做的)。
適用場(chǎng)景:
(1). Hybrid應(yīng)用,無論是Mobile的Hybrid應(yīng)用,還是PC的Hybrid應(yīng)用(桌面應(yīng)用,類似有道團(tuán)隊(duì)開發(fā)框架hex+chromium +nodejs),都非常適合,本身就不會(huì)有請(qǐng)求速度問題,這種位于客戶端代碼的應(yīng)用的代碼安全更為重要。
PS:當(dāng)然最重要的還是后端的安全,無論前端是否被破解,后端是否完善輸入校驗(yàn),是否防止越權(quán),后端才是關(guān)鍵,也就是常說一句話“不要相信用戶的任何輸入”。
2. 各個(gè)頁面大文件
各個(gè)頁面合并生成自己所需js的大文件,生成多份js合并。
優(yōu)點(diǎn):
(1). 每個(gè)頁面都用到最精確的js,不會(huì)有不相關(guān)代碼。
缺點(diǎn):
(1). 有多少個(gè)頁面,就會(huì)生成多個(gè)js,導(dǎo)致存在大量共同js代碼的冗余。
(2). 共用部分無法使用緩存優(yōu)化加載。
(3). 合并和使用會(huì)相對(duì)比較復(fù)雜。
這種方式我始終覺得不對(duì)勁,小應(yīng)用直接單個(gè)大文件搞定,而大應(yīng)用更不會(huì)這樣去做,更不能用在Hybrid應(yīng)用上,在這樣講究安裝包大小的情形下,不能容忍冗余代碼。我在思考各種場(chǎng)景時(shí)候,都發(fā)現(xiàn)能用上面或下面方式解決,而且是更優(yōu),所以我覺得這種方式是個(gè)雞肋。
3. 合并多個(gè)共用大文件
根據(jù)實(shí)踐情況合并多個(gè)共用大文件(例如依賴庫分類),再合并本頁面所需js文件(例如以業(yè)務(wù)分類),每個(gè)頁面引用一個(gè)或多個(gè)共用大文件和本頁面的js文件。
優(yōu)點(diǎn):
(1). 共用部分得到加載優(yōu)化,每個(gè)頁面引用的也盡可能的做到了不冗余。
缺點(diǎn):
(1). 多多少少還是會(huì)存在某些頁面會(huì)引用到不需要的代碼,共用不并不是完完全全的共用。
適用場(chǎng)景:
(1). 大小型應(yīng)用都比較適用,每個(gè)頁面可能存在許多共用部分,合理的分文件合并將非常關(guān)鍵。
總結(jié)
這一篇文件只是思考,也只算泛泛之談。文件合并方法挺多,由后端動(dòng)態(tài)生成或工具直接生成(grunt+requirejs),合并的方式也就以上三種,也取決于我們實(shí)踐需要。
合并很重要,但不是提倡所有文件都合并起來,有不能合并的,有些單獨(dú)文件更優(yōu)的,還是要看具體場(chǎng)景。
以上這篇前端js文件合并的三種方式推薦就是小編分享給大家的全部內(nèi)容了,希望能給大家一個(gè)參考