JavaScript框架--邁向2023年

前端面試全家桶：從求職準(zhǔn)備到面試演練2023最新

download：https://www.51xuebc.com/thread-537-1-1.html

窺視將來的巧妙之處在于，道路永遠(yuǎn)不會(huì)完整明晰。我們能夠看看趨向，看看創(chuàng)新，并嘗試制定一個(gè)道路。更好的是，我們能夠成為這些創(chuàng)新的一局部，引導(dǎo)方向。但沒有什么是肯定的。

2022 年發(fā)布了很多大型版本，推進(jìn)了 Web 開發(fā)的開展。我們看到了 Astro 和 Sveltekit 的 1.0 版本。SolidStart 和 Qwik 進(jìn)入了 Beta 版本。React 18的發(fā)布增加了對(duì)流媒體的支持，并在Next和Remix中得到應(yīng)用，同時(shí)也為React效勞器組件和Next 13應(yīng)用目錄提供了動(dòng)力。我們不能疏忽 TypeScript 對(duì)我們?cè)O(shè)計(jì)框架處理計(jì)劃的影響。從 tRPC 和 Tanstack Router 到有意見的 Next.js 元框架 create-t3-app。

我們?nèi)绾巫叩浇裉?/h2>

他們說，"專注于效勞器"。他們說："處理單頁應(yīng)用程序的權(quán)衡問題"。這并不是什么新穎事，但是人們常常不了解的是，這并不是萬靈藥。

效勞器端渲染允許我們更快地經(jīng)過更早地獲取數(shù)據(jù)來呈現(xiàn)頁面（通常更靠近我們的數(shù)據(jù)源），但也有折衷。它會(huì)減慢響應(yīng)時(shí)間，并且不會(huì)協(xié)助減小 JavaScript 包大小。由于如今需求在客戶端渲染之外的代碼來激活頁面，因而它通常會(huì)增加我們的包大小。

有一些局部的處理計(jì)劃。我們能夠更積極地停止緩存，流式處置我們的HTML響應(yīng)，并且我們能夠投資于更小/更快的框架。有一些假處理計(jì)劃：我們能夠以為漸進(jìn)式加強(qiáng)能夠替代水協(xié)作用，或者以為放棄客戶端緩存能夠有意義地改動(dòng)計(jì)算結(jié)果。劇透一下：它沒有。

我并不確信每個(gè)人都在同一頁面上，但是該范疇的許多搶先思想實(shí)踐上對(duì)某件事情有共識(shí)。這不是一件能夠輕視的事情。

我們所處的位置

單頁應(yīng)用程序并不是最合適一切的架構(gòu)。

我的意義是，這不應(yīng)該令人詫異，但是在過去的十年中，這需求一些壓服力。或許我需求對(duì)我所說的單頁應(yīng)用做一些解釋。我指的是任何典型的 JavaScript 客戶端路由和渲染架構(gòu)。以至是那些聲稱支持效勞器渲染的架構(gòu)。從 React、Next 和 Remix 到 Vue 和 Nuxt，再到 Sveltekit 和 SolidStart。

這是一種自然的演化。創(chuàng)立一個(gè)具有優(yōu)秀用戶體驗(yàn)和優(yōu)秀開發(fā)體驗(yàn)的處理計(jì)劃，人們希望將它帶到任何中央。即便是它不屬于的中央。那里是哪里？好吧，任何關(guān)懷頁面加載性能以進(jìn)步底線的中央，任何關(guān)懷低端設(shè)備和網(wǎng)絡(luò)的中央，并且能夠說任何復(fù)雜度不合理的中央。

假如我能總結(jié)出 2022 年框架思想首領(lǐng)之間最大的分歧性，那就是路由屬于效勞器。

我們并不是倡議放棄客戶端路由（雖然這是一個(gè)選擇）。只是客戶端路由和渲染架構(gòu)再次面臨著可以有效運(yùn)用的范圍的限制。

無論你是在思索 Marko、Astro 或 Fresh 及其交互性島嶼，還是 Next 和 SolidStart 的效勞器組件，你都會(huì)看到效勞器在路由職責(zé)上承當(dāng)起了重?fù)?dān)。在初始加載之后，依據(jù)導(dǎo)航渲染下一頁。即便是 Qwik，它原本能夠作為優(yōu)化的局部加載應(yīng)用程序啟動(dòng)，并且能夠擴(kuò)展到完好的 SPA，但它在一切示例和演示中都更喜歡效勞器路由（MPA）。

對(duì)2022年的深思

降服水化作用

隨著效勞器渲染成為焦點(diǎn)，水化成為一個(gè)重要的話題也就屢見不鮮了。這是我們?yōu)槊恳粋€(gè)用聲明式JavaScript框架編寫的效勞器渲染的應(yīng)用程序所付出的代價(jià)?；蛘呶覀兪沁@樣以為的。

Qwik和早期Marko 6的可恢復(fù)演示都標(biāo)明，水化很快可能成為過去。

混合嵌套式路由

在 2022 年底之前，我們看到了兩種似乎提供雙方優(yōu)勢(shì)的實(shí)驗(yàn)技術(shù)。我們得到了客戶端導(dǎo)航與after-the-fact效勞器渲染相分離的應(yīng)用程序。Next 13 應(yīng)用程序目錄看到效勞器組件與嵌套路由相分離。

固然并不是一切人都支持效勞器組件，但很難承認(rèn)，它們能夠在保存 SPA 用戶體驗(yàn)的同時(shí)，比即便是最小的 SPA 框架也可以完成的一切 JavaScript 都少得多。這是一個(gè)證明，另一種大幅減少Hydration的辦法是簡(jiǎn)單地不發(fā)送代碼。

四處都是 Signal

在 2022 年，細(xì)粒度的響應(yīng)性再次盛行起來。Vue 社區(qū)（正確地）會(huì)通知你，關(guān)于他們來說，它歷來沒有過時(shí)。但直到過去一年，我們才看到它在更普遍的范圍內(nèi)并以新的Signal旗幟呈現(xiàn)。從 Solid 共同的細(xì)粒度渲染器到 Preact 和 Qwik 運(yùn)用它來加強(qiáng)他們的虛擬 DOM 處理計(jì)劃。Marko 6 的編譯器展現(xiàn)了如何以 Svelte 相似的方式編譯細(xì)粒度的響應(yīng)性，以至 Angular 團(tuán)隊(duì)也正在積極思索添加這些原語。

TypeScript驅(qū)動(dòng)的開發(fā)

2022年，TypeScript從一個(gè)選項(xiàng)變成了許多元框架CLI的默許選項(xiàng)。

tRPC改動(dòng)了游戲規(guī)則，但在這一年里，我們看到JavaScript元框架也在思索這個(gè)問題。從SolidStart的編譯類型平安的RPC到Remix和Next的數(shù)據(jù)加載機(jī)制的改良。

Tanstack Router向我們展現(xiàn)了類型平安路由的容貌，如今曾經(jīng)沒有回頭路了。我們依然看到這些技術(shù)在向外傳播，但收益是如此之大，當(dāng)這些技術(shù)存在時(shí)，人們將不會(huì)承受以前的開發(fā)方式。

轉(zhuǎn)向 2023 年

復(fù)雜性中的爭(zhēng)論

這將在新的一年繼續(xù)成為一個(gè)主題。你不能在短時(shí)間內(nèi)在一個(gè)范疇傾注大量創(chuàng)新，而不希望呈現(xiàn)什么問題。Astro 和 Remix 分別回歸到“這只是 PHP/Rails”的 MPA 和 SPA，固然它們都短少更復(fù)雜處理計(jì)劃的重要優(yōu)勢(shì)，但都獲得了很大勝利。

在Qwik和Marko中花了很多時(shí)間用于MPA，在React和Solid的混合路由處理計(jì)劃中花了很多時(shí)間用于Server Components的滋味，這里仍有一些東西需求學(xué)習(xí)。當(dāng)自定義言語效勞器插件是堅(jiān)持效勞器組件的獨(dú)一辦法，或者你需求成為代碼中發(fā)作序列化邊境的專家時(shí)，你就需求開端質(zhì)疑了。

這些技術(shù)是將來的趨向。但我們需求記住，我們并不是第一個(gè)嘗試這樣做的人。后臺(tái)技術(shù)在2000年代中期就曾經(jīng)嘗試過了，相反，我們根本上都轉(zhuǎn)向了SPA。我們需求答復(fù) "這次有什么不同？"

這可能依然要?dú)w結(jié)為答復(fù)這個(gè)問題：我們能否置信最終能夠發(fā)送到閱讀器的內(nèi)容應(yīng)該被發(fā)送，還是效勞器是一個(gè)我們應(yīng)該共同應(yīng)用的中央？隨著 MPA 和 SPA 之間的障礙消逝，這種劃分很可能會(huì)以新的方式呈現(xiàn)。

Edge ：不曾探究的邊境

在過去的 12 個(gè)月中，簡(jiǎn)直一切元框架都支持了邊緣函數(shù)。在這一點(diǎn)上，絕大多數(shù)元框架都能夠部署到各種效勞器less 和邊緣產(chǎn)品中。但是，這并沒有改動(dòng)我們的開發(fā)方式。

我們很快就會(huì)指出，數(shù)據(jù)并不在邊緣上。而我們應(yīng)該假定，即便在處理邊緣問題的時(shí)分，也不是一切的數(shù)據(jù)都會(huì)在邊緣上。

邊緣需求超越單體部署。我們需求弄分明如何將計(jì)算分配到合理的位置。我不是在議論微前端或微效勞。而是單體軟件的散布式部署。我不曉得這是什么樣子，但我置信我們會(huì)在接下來的 12 個(gè)月內(nèi)找到答案。

其他技術(shù)

2023年將最終成為 Web 組件的一年嗎？

就像今年將成為Linux桌面年一樣。隨你怎樣想。

2023年將是WASM的一年嗎？

可能還沒有。但悄然地，WASM曾經(jīng)發(fā)現(xiàn)本人比以前適用于更多的空間。這包括DOM渲染。我們以為我們所了解的開支并不是我們所想的那樣，最快的WASM Rust庫曾經(jīng)在客戶端渲染上與JavaScript拉開了差距。

關(guān)于很多事情來說，頁面負(fù)載依然是一個(gè)令人望而卻步的指標(biāo)，但你依然能夠用WASM做漸進(jìn)式加強(qiáng)。因而，假如它對(duì)Remix來說足夠好，對(duì)你來說可能也足夠好。

2023年，人工智能/低代碼會(huì)搶走我的工作嗎？

不。但它可能協(xié)助你將代碼從一個(gè)框架遷移到另一個(gè)框架。

總結(jié)

過去大約 5 年相對(duì)寂靜之后，在過去一年左右呈現(xiàn)了新的框架。這不是我們中止制造它們的緣由，而是機(jī)遇曾經(jīng)成熟了。

即便大公司也在與系統(tǒng)重置技術(shù)（如 Server Components）、新的 Virtual DOM-less 編譯器（如 Vue Vapor）和新的變卦機(jī)制（如 Signals）調(diào)情。

但目前還沒有明白的方向?，F(xiàn)有的辦法曾經(jīng)到了極限。激進(jìn)的新辦法是不完好的，無論采取什么方式，都會(huì)將復(fù)雜性轉(zhuǎn)嫁給開發(fā)者。試圖將其埋藏在元框架中的做法只獲得了一定的勝利。