[點(diǎn)晴永久免費(fèi)OA]JavaScript,是時(shí)候瘦瘦身了!
導(dǎo)讀 “Javascript太重了。”雖然JS在全球開(kāi)發(fā)語(yǔ)言中屬于巨無(wú)霸的存在,但從過(guò)去到現(xiàn)在,吐槽JS的聲音一直不絕于耳。 作者 | Loraine Lawson 編譯 | 言征 “Javascript太重了。”雖然JS在全球開(kāi)發(fā)語(yǔ)言中屬于巨無(wú)霸的存在,但從過(guò)去到現(xiàn)在,吐槽JS的聲音一直不絕于耳。 比如,要系統(tǒng)的學(xué)Javascript,有一大套工具鏈,而且是非官方的工具鏈。許多新手一看到VS Code,NodeJS,Babel,Webpack,Jest,Gulp, Typescript...頓時(shí)就被勸退。 再比如,語(yǔ)法特性也是亂成一團(tuán)。弱類型,又可以面向?qū)ο螅挚梢院瘮?shù)式編程,還可以面向過(guò)程,還有this關(guān)鍵字,這些全部混著用。誰(shuí)也不想接受這樣的屎山代碼! 就連Solid.js框架的創(chuàng)建者Ryan Carniato,也在近日發(fā)聲:是時(shí)候在Web中減少JS代碼了! 一、采用 0 Kb Javascript?做不到!Carniato目前在Web開(kāi)發(fā)平臺(tái)Netlify任職,近期他在“International Javascript”會(huì)議的主題演講中向前端開(kāi)發(fā)人員提出了一個(gè)問(wèn)題:“你未來(lái)會(huì)采用 0kb Javascript 嗎?” 當(dāng)然,Carniato提出的這個(gè)問(wèn)題更多是是一個(gè)假設(shè)性問(wèn)題,因?yàn)?0kb 并不是真正的目標(biāo)。更重要的是前端需要減少其Javascript的占用空間。 “如果我們回顧過(guò)去和現(xiàn)在,就會(huì)發(fā)現(xiàn)關(guān)于降低 Javascript 成本的討論一直在進(jìn)行,而且證據(jù)充分確鑿?!?/span> 首先,他給開(kāi)發(fā)人員展示了一組統(tǒng)計(jì)圖數(shù)據(jù),圖中顯示了按內(nèi)容類型劃分的網(wǎng)頁(yè)權(quán)重的中位數(shù),很明顯,除了意料之中的圖片之外,讓網(wǎng)頁(yè)變得十分“沉重”的罪魁禍?zhǔn)妆闶荍avascript。
如何讓網(wǎng)頁(yè)變輕?“首先,如何優(yōu)化圖像是眾所周知的,但 Javascript 有點(diǎn)棘手,而且它恰好是所提供的最昂貴的資產(chǎn)之一,”他說(shuō)。 同時(shí),Carniato指出,這種情況在移動(dòng)設(shè)備上則是一個(gè)更大的問(wèn)題,根據(jù)設(shè)備和網(wǎng)絡(luò)的不同,要代價(jià)可能“非常高”。 他展示了一個(gè) Javascript 大小為 170 KB 的示例。Javascript的處理時(shí)間要比圖像更“漫長(zhǎng)”。 “在一臺(tái)低端設(shè)備上,處理時(shí)間,即解析、執(zhí)行、運(yùn)行 Javascript 代碼的時(shí)間,幾乎是3秒半,而圖像大約是 100 毫秒左右?!?/span>
而且,高端設(shè)備和低端設(shè)備之間處理能力的差異,也存在越來(lái)越明顯的差距。2022 年的低端設(shè)備市場(chǎng)在處理能力方面與 2014 年的高級(jí)設(shè)備類似,因此 iPhone 6s 本質(zhì)上就像擁有 Moto E 30。 這里,Carniato提到了尤其會(huì)對(duì)電商公司 eBay 造成不小的影響,因?yàn)樵陔娮由虅?wù)領(lǐng)域,頁(yè)面加載至關(guān)重要。 “加載時(shí)間和購(gòu)買率之間存在相關(guān)性,這已經(jīng)不是什么秘密了,”他說(shuō)?!皢?wèn)題的真相在于水合(Hydration),而大型 Javascript 有效負(fù)載也是我們架構(gòu)責(zé)任的一部分?!?/span> 名詞解釋:1.水合作用的實(shí)質(zhì)是水分子整體進(jìn)入礦物晶格,從而使礦物體積增大的作用。這里是指 Web開(kāi)發(fā)中的一種交互性技術(shù)。 在web開(kāi)發(fā)中,水合(Hydration)是一種為服務(wù)器渲染的HTML添加交互性的技術(shù)。這是一種客戶端Javascript通過(guò)將事件處理程序附加到HTML元素,將靜態(tài)HTML網(wǎng)頁(yè)轉(zhuǎn)換為動(dòng)態(tài)網(wǎng)頁(yè)的技術(shù)。 近年來(lái),水合開(kāi)始被視為一個(gè)消耗內(nèi)存并減慢啟動(dòng)速度的黑客,尤其是在移動(dòng)設(shè)備上。 二、前端開(kāi)發(fā)者該為Javascript瘦身了!Carniato 給出了為Web中 Javascript 代碼“瘦身”的幾種策略。 1.代碼分割/延遲加載Carniato 說(shuō),代碼分割和延遲加載可以顯著減輕重量。“現(xiàn)在使用的幾乎所有元框架或工具幾乎都會(huì)在路線級(jí)別自動(dòng)為您完成此操作,”他說(shuō)?!八阅銘?yīng)該已經(jīng)這樣做了。” 關(guān)于框架如何水合需要了解的一件事是,服務(wù)器渲染的任何內(nèi)容都需要水合,就好像它在頁(yè)面上可見(jiàn)一樣,這就是開(kāi)發(fā)人員顯示其他內(nèi)容并將其交換的原因。確實(shí)需要一些手動(dòng)操作才能完成這項(xiàng)工作,他補(bǔ)充道,因?yàn)槿绻承〇|西確實(shí)存在于投降 DOM 中并且它應(yīng)該是交互式的,那么它就會(huì)水合。 “延遲加載并不能阻止它。這就是這些框架的工作方式,因?yàn)樗鼈兓旧闲枰\(yùn)行整個(gè)應(yīng)用程序,”他補(bǔ)充道。 2.使用更小/更快的框架Carniato 采用了一種有趣的方法來(lái)比較框架。他在開(kāi)始時(shí)查看了它們的大小,然后隨著更多組件添加到框架中。結(jié)果令人驚訝,因?yàn)榭焖倏蚣懿灰欢ū3挚焖佟?/span>
“是的,你的基線 [...] 開(kāi)始較小,但實(shí)際上一旦編寫(xiě)代碼情況就變了,”他說(shuō)。“因此,在某個(gè)時(shí)刻,這些組件會(huì)構(gòu)成更大的一塊?!?/span> 有些框架一開(kāi)始很小,但隨著組件的添加,框架開(kāi)始相互接近。他以 Svelte 為例?!袄纾琒velte 從最小的開(kāi)始;當(dāng)你擁有 80 個(gè)獨(dú)特的組件時(shí),它實(shí)際上比 React 和其他所有組件都大,”他說(shuō)。 “所以大多數(shù)框架實(shí)際上在規(guī)模上非常相似,事實(shí)上,你可以看到最上面的那條線,那就是在開(kāi)頭的React——它有相同的斜率?!?/span> 3.漸進(jìn)式增強(qiáng)漸進(jìn)式增強(qiáng)基于這樣的理念:Web是建立在anchors 和表單之上的;他解釋說(shuō),因此,如果 Javascript 不存在,開(kāi)發(fā)人員可以依靠平臺(tái)中已經(jīng)內(nèi)置的內(nèi)容。 “漸進(jìn)式增強(qiáng)確實(shí)得到了很大的推動(dòng),特別是在 Remix 和 SvelteKit 這樣的框架中,”他說(shuō)?!爸灰獙⑺薪换ゾ帉?xiě)為anchors 和表單,那么它們無(wú)需 Javascript 即可運(yùn)行。我認(rèn)為這是一件很棒的事情?!?/span> 不過(guò),Carniato 認(rèn)為,它不一定能替代其他減少JS代碼的方法,但它的確創(chuàng)造了一種非常不同的體驗(yàn)。 “我之前提到的那個(gè)可憐的用戶,他使用的手機(jī)需要3秒半的時(shí)間來(lái)加載解析——假設(shè)總共需要7秒才能進(jìn)行交互——他們點(diǎn)擊鏈接可見(jiàn)3秒的鏈接,已經(jīng)過(guò)去6秒,”他說(shuō)?!澳悴略趺粗??Javascript 還沒(méi)有加載。” 因此,現(xiàn)在他們必須重新加載整個(gè)頁(yè)面并再次等待七秒鐘,而不是使用一些可供性進(jìn)行客戶端導(dǎo)航,他補(bǔ)充道。 “這當(dāng)然OK,但這實(shí)際上并不是完全的勝利,它并不能解決問(wèn)題,” 4.漸進(jìn)式水合(Progressive Hydration)他說(shuō),漸進(jìn)式水合背后的想法是,頁(yè)面根據(jù)需要進(jìn)行水合。當(dāng)有人點(diǎn)擊文檔時(shí),開(kāi)發(fā)人員可以提前將一些事件處理程序附加到文檔,然后用它來(lái)做一些聰明的事情。他補(bǔ)充說(shuō),有時(shí)這被稱為選擇性水合。
Twitter上一位專家Dan Abramov為 Carniato 繪制了上圖,試圖展示如果 React 還沒(méi)有完全水合,并且有人點(diǎn)擊不同的分支(可能不是 React當(dāng)前正在加載或水合的分支)會(huì)發(fā)生什么,那么它就會(huì)足夠聰明地?cái)[脫它正在做的事情,然后優(yōu)先考慮被點(diǎn)擊的那個(gè)分支。 “它仍然必須從父節(jié)點(diǎn)到子節(jié)點(diǎn),但你可以給中間節(jié)點(diǎn)做水合,而不是繞過(guò)去;對(duì)我來(lái)說(shuō),無(wú)阻塞在這種情況下非常好,”Carniato 說(shuō)道。 但事情也不是絕對(duì)的,你可能不會(huì)注意到,有時(shí)這也會(huì)導(dǎo)致總時(shí)間更長(zhǎng),另外,你會(huì)發(fā)現(xiàn),后臺(tái)中的CPU會(huì)嘎嘎作響,可能會(huì)在一定程度上影響體驗(yàn)。 此外,Carniato 還給出了其他幾種 Javascript 瘦身的辦法,后續(xù)我們會(huì)跟蹤報(bào)道,也歡迎諸位在評(píng)論區(qū)探討交流。 最后想說(shuō)一句,有人認(rèn)為拋開(kāi)Javascript的龐大生態(tài),去吐槽Javascript太臃腫,有點(diǎn)耍賴皮,誰(shuí)讓現(xiàn)在基本所有的Web都在用它呢! 參考鏈接 https://thenewstack.io/solid-js-creator-outlines-options-to-reduce-javascript-code/ 責(zé)任編輯:華軒來(lái)源: 51CTO技術(shù)棧
該文章在 2023/10/28 17:30:53 編輯過(guò) |
關(guān)鍵字查詢
相關(guān)文章
正在查詢... |