JavaScript框架--邁向2023年

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

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

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

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

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

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

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

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

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

我們所處的位置

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

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

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

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

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

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

對2022年的深思

降服水化作用

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

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

混合嵌套式路由

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

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

四處都是 Signal

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

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

2022年，TypeScript從一個選項變成了許多元框架CLI的默許選項。

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

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

轉(zhuǎn)向 2023 年

復(fù)雜性中的爭論

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

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

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

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

Edge ：不曾探究的邊境

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

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

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

其他技術(shù)

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

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

2023年將是WASM的一年嗎？

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

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

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

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

總結(jié)

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

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

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