尤雨溪解讀 2022 Web 前端生態趨勢

尤大大從下面的三個前端領域的不同層次來展開了介紹：

• 開發範式 & 底層框架（注：大家比較熟悉的 Vue、React 這些框架層面）

• 工具鏈（注：像 webpack 這樣的構建工具）

• 上層框架（注：例如 Next.js、Nuxt.js）

正式分享之前，尤大大提出聲明：“本分享只代表講着個人觀點，因爲自己是框架和構建工具的作者，肯定會包含利益相關和個人的偏見，但是分享中會盡可能做客觀的看法，大家多多多包涵”，下面就讓我們飽享這頓 “美味” 吧！

下面的內容是根據尤大大的分享進行了一定的抽離和少許的個人總結，如果內容出現歧義可以在評論區留言！

開發範式 & 底層框架方面趨勢

過去幾年中影響最大的開發範式層面的變化肯定就是我們的 React Hooks 隨着他的推出可以說是啓發了很多組件邏輯表達和邏輯複用的新範式，在 React 生態中徹底取代了 Class Components ，包括現在其實很少能夠在 React 中看到 Class Components 了，

不僅如此，其實在其他的框架中 React Hooks 也產生了很大的影響，比如說我們 Vue 推出的 Vue Composition API 組合式 API，還包括受到 React Hooks 的啓發的 Svelte3 ，更有 SolidJS 他是語法上相似於 React Hooks 實現上更相似於 Vue Composition API 。

隨着 React Hooks 的推廣和開發者對其的廣泛使用，他開發中的一些體驗問題也逐漸被正視，這裏不可迴避的一些體驗問題的根本原因有以下幾點：

• Hooks 執行原理和原生 JS 的心智模型的差異：因爲 React Hooks 是通過把組件的代碼每一次更新都進行重複調用來模擬一些行爲，從而導致反直覺的一些限制；

• 不可以條件式的調用 React force ；

• Stale Closure 的心智負擔：如果你不傳正確的依賴數組，那麼就會產生過期閉包；

• 必須手動聲明 use Effect 依賴；

• 如何‘正確’使用 use Effect 是個複雜的問題；

• 需要 useMemo/useCallback 等手動優化，否則的話就會不知不覺的導致一些性能問題；

尤大大表示作爲競爭框架的作者，對 React Hooks 框架的看法可能相對更直接一些，但這些也並非尤大大一個人的看法，而是近年來 React 社區和 React 團隊也已經意識到的問題，當然 React 團隊針對這些問題也在做改善的努力，據代表性的改善從下三個方面：

基於依賴追蹤範式

在上面的這些改進之前，其實很多 React 的社區成員也包括一些本身就不適用 React 的用戶來說，雖然 React Hooks 產生了重大的影響但是大家也意識到了他的一些問題，反而是一些跟 React Hooks 相似的一些邏輯組合能力，另一方面基於依賴追蹤的範式開始重新得到了重視；比如在 React 內部的 Recoil ，當然在社區之外就有更多了比如：

我們可以看一下就基於依賴追蹤的範式而言上面三個方案的代碼：

SolidJS

//狀態
const [count,setCount] = createSignal(0)
//副作用
createEffect(() => console.log(`${count()`}
//狀態更新
setCount(count() + 1)

能夠看出其實 SolidJS 和 React Hooks 非常相似

• 副作用中的 createEffect 跟 React 中的 use Effect 其實是類似的，但是 createEffect 並不需要去聲明依賴，在調用 count 函數的時候其實幫你收集了依賴；

• 狀態更新的時候我們也並不需要用到 useCallback 這種額外的方式去創造函數來去傳遞給我們的事件偵聽器；這些都是非常符合直覺的；

Vue Composition API

//狀態
const count = ref(0)
//副作用
watchEffect(() => console.log(count.value))
//狀態更新
count.value++

其實 Vue 中使用的 Composition API 跟 SolidJS 本質上的內部實現幾乎是一樣的，只不過 SolidJS 看起來更像是 React ，而 Vue 是通過一個 ref 對象，對象上的 value 機可以讀也可以寫，在讀和寫之中就會自動的追蹤和更新依賴。

Ember Starbeam

//狀態
const count = Cell(0)
//副作用
DEBUG_RENDERER.render({render: () => console.log(count.current)})
//狀態更新
count.set(prev => prev + 1)

Ember Starbeam 中的這個 Cell 其實就和 Vue 中的 ref api 幾乎是一樣的，暴露出 count 爲當前的值和 set 方法來進行狀態的更新

基於依賴追蹤範式—共同點

上面提到的三種基於依賴追蹤的範式他們的共同點有什麼呢？

同時以依賴追蹤爲一等功名概念的框架中，本身組件的設計肯定也是跟依賴追蹤有緊密的結合，所以組件的更新渲染也會有自動的依賴追蹤，也就是說組件的更新會更精確，而不再依賴於一個狀態從父組件到子組件一層層傳遞下去，而是每一個即使是深層嵌套的組件也可以自發的更新，整體上的性能會更好。

在 react 生態中的 Recoil 這樣的方案，雖然也提供了依賴自動的依賴追蹤和一定程度的逐漸的更新優化，但是因爲他們仍然是需要在 React Hooks 的這個大的體系中使用的，所以在很多其他的方面依然會受制於 hooks 的問題，那麼 Hooks 本身在這些方案之外，還是會存在過期閉包等等 user fact 這些問題。

React Hooks 確實是啓發了一個新範式的時代，但是慢慢的我們也發現他自己自身存在的一些問題，當然 React 團隊正在試圖解決這些問題，同時在 React 體系之外，開始有一些其他的具有同等的邏輯組合能力，但同時避免了 React Hooks 這些問題的這些方案存在，也漸漸的收到了前端社區的重視。

基於編譯的響應式系統

不過即使是基於依賴追蹤的方案，我們也可以進行一些基於編譯時的這個優化，那這裏首當其衝的就是 Svelte3

Svelte

Svelte3 從一開始就是一個編譯時優化方案，上面就是 Svelte 組件中的一個使用狀態的代碼，我們看到他跟他的狀態就是這個 javaScript 的這個 let 這樣聲明一個變量，就是一個響應式的狀態，那麼你要更新這個狀態就直接去操作這個變量就可以，

副作用是用一個神奇的編譯式的魔法，也就是這個 $ ，這個 $ 的一個 label，這其實是 javaScript 的一個 label 語法來聲明， $ 之後的這個語句會自動去追蹤count這個變量的變化，當count變化的時候，這個語句就會自動重新執行，那麼我們可以看到這個跟我們之前的這個幾個代碼範例，他所達成的目標其實是一致的，只是他使用編譯的手段使代碼變的更加簡潔，但也正是因爲簡潔所以存在下面的限制：

Vue Reactivity Transform

也正是受到上方的限制的啓發，Vue 在 3.2 的時候引入了一個實現性的功能 Vue Reactivity Transform 響應式轉換 ，下面就是 Vue 轉化後的一段代碼：

還是一個簡單的變量聲明，但是我們用一個 $ref 這樣的一個函數，這個函數其實是一個編譯時的一個宏的概念，這個函數並不是真實存在的，只是給編譯一個提示，那編譯器通過編譯之後就會把它轉化成我們之前看到的基於真實的 ref 的代碼。

但是在使用時候，體驗就變成了只是聲明一個函數，然後使用這個變量和更新這個變量就跟使用一個普通 javaScript 變量沒有區別。同時這個語法因爲在聲明的時候會顯式的聲明，說哪個變量是響應聲，哪個變量不是響應式。

所以這個語法可以在嵌套的函數中使用，也可以在 TS/JS 文件中使用，他並不限制於 Vue 文件，所以這是一個更加樸實的編譯響應式模型。

Solid -labels

在 Solid 的生態中，其實也受啓發於 Vue Reactivity Transform ，他的社區用戶做的一個 Solid-label，也是基於 Solid 的響應式方案，然後再做一層編譯式的優化，那麼可以看到跟 Reactivity Transform 能夠達成的效果是非常相似的。

那最終的目的就是讓大家可以用更簡潔的代碼去表達組件邏輯，同時又不放棄這個邏輯組合，像 React Hooks 那樣進行自由的邏輯組合的這些能力啊。所以說這也是一個很有意思的探索方向。

統一模型的優勢和代價

優勢： 和Svelte相比，Vue 的 Reactivity Transform 和 Solid \-labels 都屬於統一模型，也就是他不受限於組件上下文，它可以在組建內使用，也可以在組建外使用，優勢就是有利於長期的重構和複用，因爲很多時候我們的大型項目中的邏輯複用都是在我們一個組件寫着寫着發現這個組件變得很臃腫，很大的時候我們纔開始考慮要把邏輯開始重新組織抽取複用，那麼由於 Svelte 的語法只能在組件內使用，就使得把邏輯挪到組件外成爲一個代價相當大的一個行爲，並不是一個簡單把文把這個邏輯拷貝複製出去，而是需要進行一次徹底的重構，

因爲組件外用的是完全一套不同的系統，但是像用 Reactivity Transform 和 Solid \-labels 這樣的方案呢，我們就可以把組件內的這些邏輯原封不動的直接拷貝到組件外，然後把它包在一個函數里面，抽取就完成了，那麼這樣重構時的這個代價就非常小，也就更鼓勵團隊的這樣的優化，對於長期的維護性更有幫助。

代價： 因爲我們需要顯示的去聲明響應式的變量，所以它會有一定程度的底層實現的抽象泄露，也就是說，用戶其實是需要先了解底層的響應式模型的實現，然後才能更好地理解這個語法糖是如何運作的，而不像 Svelte 組建中的這個語法，即使你完全不瞭解他底層如何運作的也可以，幾乎可以零成本的上手，這就是一個長期的可維護性和一個初期的上手成本之間的一個平衡和取捨。

基於編譯的運行是優化

講完了狀態管理，我們在還可以聊一聊關於基於編譯的運行時優化，編譯的運行時優化又是三個主要的代表，如上圖所示，那首先我們可以看一下不同的這個策略：

Svelte 的這個代碼生成策略相對更更繁瑣一些，而 Solid 是基於先生成一個基本的 HTML 字符串，然後在裏面找到對應的 DOM 節點進行綁定，而 Svelte 是通過生成一這個命令式的一個一個節點，然後把節點拼接的這些 javaScript 代碼，但這個策略就導致掉同等的這個組件源碼之下 Svelte 的每個組件的編譯輸出會更臃腫，所以雖然大家感覺 Svelte 是以輕量出名的，

但其實我們會發現在相對大型的項目中，在項目中組建超過 15 個之後，Svelte 的整體的打包體積優勢就已經幾乎不存在了，那麼當組建超過 50 個，甚至是達到 100 個的時候，所有的體積會越來越越來越臃腫。

而相對於而言，我們可以看到 Vue 和 Solid 的編譯這個輸出啊，整體的這個曲線就平緩很多，所以其實在越大型的項目中。反而是 Svelte 的體積優勢反而是一個劣勢，據我所知，Svelte 團隊也有在想要優化這一方面的，可能會在下一個大版本中才能實現，那麼我們也會拭目以待。

同時尤大大提出 Solid 的編譯性能確實是非常的猛，其實在我們的 Vue 引入了很多編譯時的優化以後我們的性能已經比 Svelte 好了，但是離 Solid 還是有一定的距離。

Vue Vapor Mode（input）

就上面提及到的編譯時性能優化，其實我們的 Vue 在早期的時候也做了這方面的探索，如還在試驗中的一個項目 Vue Vapor Mode 。

那同樣的這個只有單文件組件輸入，我們現在是通過把模板編譯成虛擬DOM 的一個渲染函數來進行運行時的實現。但是因爲模板是一個編譯源，所以我們也可以選擇在另一個模式下把它編譯成不同的輸出，也就是一個更類似於 Svelte 輸出。

這裏這個輸出的代碼只是一個示例代碼。並不一定是最終的代碼，也不是你需要書寫的代碼，它完全是一個編譯器的輸出啊，它的整體的思路就是一次性生成這個模板的靜態結構、靜態節點，然後再去生成命令式的，找到動態節點，並對把它跟狀態進行響應式的綁定的這樣一些代碼，這個策略本質上就是 Solid 所採用的策略，

那麼其實呢，這個策略可以被所有的模板引擎所使用，我們也在探索某個版本的 Vue 當中會引入一個可選的這樣的一個模式，把模板編譯成這樣的，性能更優的，運行時的這個體積也更小的一個模式，當然這不會是一個破壞性更新，因爲我們的目標是可以讓你漸進式的去使用這個功能。

工具鏈

原生語言在前端工具鏈中的使用

關於原生語言在前端工具鏈中的使用尤大大提出下面幾個見解：

工具鏈的抽象層次

最早的打包工具，包括 brow/webpack/rollup 他們都是專注於打包的，他們的抽象層次相對低，當你想要用這些工具去做一個真正的應用的時候，你需要使用大量第三方插件，以及大量的配置來達到一個滿足你自己要求的最終的形態。

那麼在這個基礎上就產生了像 Parcel/Vue-cli/CRA ，這樣的一些所謂的腳手架，更高抽象層次的這些工具，這些工具的特點是他們的抽象層的高，也就說他們專注於應用，專注於解決一個完整的應用方案呢，它的相對而言的缺點就是它是一個比較複雜、比較龐大的一個黑盒兒。

當你需要去進行自定義的定製的時候，你就會不可避免的遇到一些問題，比如說你跟他默認的功能產生一些意見上的衝突的時候，你就會比較痛苦。

那麼我們現在做的這個新項目 Vite 其實可能有一些同學已經在用了，其實我們是在思考過這個抽象層次的問題之後才決定的他要走一個怎麼樣的路線，也就是說 Vite 的 CLI 它是專注於應用層次啊，它的抽象層次高，它有很多的開箱記，就是事先幫你寄配置好的功能，那麼大部分的情況下，你開箱即用就可以達到跟 Parcel/Vue-cli/CRA 幾乎同等的這些功能啊，但是我們的API層面啊，這個可能用到的同學會少一些，

但是它的API層面其實是專注於支持上層框架，我們這個抽象層次會更低一點，我們只解決一些所有的夠 meta framework 都必須要解決的問題，但是對於上層框架，你用什麼，我們並不會做過多的限制，反而是要做的更儘可能的靈活，能夠支持任何上層框架的用例，所以這也是爲什麼 Vite 現在幾乎成爲了下一代的meta framework 共同的一個基底層選擇。

基於 Vite 的上層框架

我們看到上面這麼多的上層框架都在基於 Vite 說明我們 Vite 走的路線還是相對成功的。

上層框架 Meta Frameworks

JS 全棧的意義是什麼 ？

如果我們講到這個 Meta Frameworks，也就是最典型的例子，也就是NextJS 、NuxtJS、以及現在 React 社區中的新秀 Remix 等等，那麼當我們思考這樣類型的 JS 全棧的時候，我們做全棧的意義是什麼？

那麼相信在國內很多大企業的朋友都知道，因爲我們可以用同一個語言去做前後的連接，我們可以做一些純前端和純後端都各自做不到的事情，或者說之前需要很複雜的聯調才能達成的一些事情，那麼 JS 全棧可以更好的去完成一個語言讓我們可以把前後打通。那麼我們能夠打通什麼呢？

數據的前後端打通

類型的前後端打通

JS 全棧的代價

一些新的全棧框架，現在在試圖去改善的一些問題首先。我們現有的這些前端框架，比如說像主流的像 React、Vue 我們在做了服務端渲染之後，還需要在前端要進行一次所謂的注水，也就是 Hydrate 在追尋的過程中，我們要確保在客戶端和前端有同樣的數據，所以其實雖然我們的數據已經用於渲染 HTML，

這些數據理論上在 HTML 裏面已經都用過了，但是我們還得再把這個數據再發送一次，一起發送到前端，讓前端去進行 Hydrate 這樣一個過程。因爲沒有這個數據，我們在前端就沒有辦法保證 Hydrate 的正確性啊。

在客戶端，有些組件它可能在客戶端是不，需要交互的是靜態的，但是他在服務端用到了動態的這個數據，但這個組件依然會被髮到服務端，它依然會可能產生這個javascript 運行時的代價啊，以及緩慢的這個 Hydrate 會影響頁面的交互指標，也就是 time to interactive。

有一些比較複雜的龐大的項目，他可能這個注水的過程會把頁面卡頓，以至於雖然能看到頁面，但是沒法交互，要等個一秒鐘才能交互等等，會產生這樣的問題。

社區探索的方向

社區現在新一代的這些全棧框架都在試圖解決這些問題啊，比如說像 React 提出了 server only components 其實從這個定義上，我們就發現他是沒有一個全棧框架，圍繞一個全棧框架去做，其實用戶是沒有辦法簡單地使用的一個概念，所以 React server only components 其實是一個必須要全站才能做的概念，Next 當然也會去做，

然後，其實 Nuxt 最近也開了一個 server only components 的一個提案，所以說這個已經就是說 server only components 其實不僅僅是一個 React 獨有的概念，在很多其他的框架中，我們可能慢慢都會出現類似的這個類似的東西。

還有一個方向就是減少注水，hydration 的這個成本，那麼也就是局部的注水，或者也叫 island architecture 就像大海中一個小島，只有這些小島去對他進行注水，讓他交可交互啊。那麼比較代表性的就是 astro、isles 和生態裏面的 fresh 這些框架。

然後呢，還有一個探索方向，就是所謂的 fine-grained+resumabl hydration，就是細粒度懶加載，這個數據其實是Qwik這個框架所發明的，Quick 的作者就是 Misko Hevery，也就是 Angular 的原作者，離開 Google 之後，現在新開發的這個框架啊，那麼 Qwik 它主打的就是說它的特點就是不需要再把數據重新發送一遍。

他是直接在生成的渲染的 html 裏面嵌入所需的數據從而使得客戶端的 js 可以直接在 html 裏面獲得所要的數據，甚至是可以跳過一些需要執行的 js 步驟，直接跳到一個已經完成的狀態上面去，這就是所謂的resumable ，也是一個比較值得關注的一個方向。

以及我們的 Vue 生態裏面生態裏面有一個我們的 VitePress，我們其實探索的是一個在我們頁面的核心內容：其實是靜態的 MD 文件的前提下如何做高效率的 hydration 那麼我們做的是所謂的 hydration 就是整個的外部的這個一個框架內容外包着的這一層 ui 是動態的，然後呢在內部靜態的裏繼續進行局部的注水，然後這樣的話，我們依然可以獲得一個單頁應用的體驗，但又獲得很好的客戶端注水的性能。

寫在最後

到這裏呢尤大大的分享就結束了，本總結的內容中如果存在爭議大家可以在評論區進行留言，希望能夠給大家帶來一定的收穫和成長！

作者：幾何心涼

https://juejin.cn/post/7124551017382805518

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/-YWJ5-GrMsuNHEqcFW9-aA