大家好，我卡頌。

近幾年，前端領(lǐng)域出現(xiàn)了很多新框架，比如??Svelte???、 ??Solid.js???、??Astro???、??Qwik??等。

伴隨他們出現(xiàn)的，還有很多「高大上」的新概念 —— 「運(yùn)行時(shí)/編譯時(shí)框架」、「Islands架構(gòu)」、「Selective Hydration」......

這些概念的本質(zhì)，就是「通過(guò)各種方式，讓頁(yè)面更快」。

這里的「快」主要包括兩方面：

• 讓HTML加載更快（一眾和SSR相關(guān)的概念與此有關(guān)，比如「Islands架構(gòu)」）
• 更快響應(yīng)交互（一眾采用「細(xì)粒度更新」的框架與此有關(guān)，比如Vue、Solid.js）

但是，「快」就是評(píng)價(jià)Web未來(lái)發(fā)展方向的唯一標(biāo)準(zhǔn)么？

一位有32年開(kāi)發(fā)經(jīng)驗(yàn)的老程序員在他的博文[1]中提出了不同的觀點(diǎn)。

本文是對(duì)該博文的部分解讀。

對(duì)應(yīng)用來(lái)說(shuō)，什么才是重要的？

上面提到，現(xiàn)在前端框架的新特性，是「通過(guò)各種方式，讓頁(yè)面更快」。

這里的主語(yǔ)是「頁(yè)面」而不是「應(yīng)用」。

事實(shí)上，雖然開(kāi)發(fā)者經(jīng)常談?wù)揥eb App，但大部分開(kāi)發(fā)者開(kāi)發(fā)的，只能稱為頁(yè)面。

頁(yè)面與應(yīng)用的一大差別，就是「交互體驗(yàn)的差異」。

如果一個(gè)頁(yè)面中某些交互類似IOS原生應(yīng)用，我們會(huì)說(shuō)這個(gè)頁(yè)面交互做的很棒。

所以，雖然「速度快」是交互體驗(yàn)中重要的一環(huán)，但絕不是全部，還有大量細(xì)節(jié)值得考慮。

以業(yè)界用戶體驗(yàn)的標(biāo)桿Mac OS舉例：

• 在Mac OS中，打開(kāi)應(yīng)用的狀態(tài)欄時(shí)，按住「command + option」之類的快捷鍵能夠開(kāi)啟進(jìn)階功能：

按住command + option前

按住command + option后

• 撤回（command + z）操作的結(jié)果對(duì)各種操作目標(biāo)都是符合預(yù)期的（不管目標(biāo)是文本還是文件等）。
• 富文本內(nèi)容的復(fù)制、粘貼與富文本內(nèi)容通過(guò)拖拽的表現(xiàn)一致。

做過(guò)富文本編輯器的同學(xué)應(yīng)該能感受到上述功能的難度

上述這些「符合預(yù)期」的細(xì)節(jié)背后，是一套「響應(yīng)式系統(tǒng)」。

響應(yīng)式系統(tǒng)

Mac OS X?是第一款聲稱自己為「響應(yīng)式」的操作系統(tǒng)。在此之前，業(yè)界的效仿對(duì)象是Windows操作系統(tǒng)。

在Windows中，數(shù)據(jù)是「非響應(yīng)式」的。除非開(kāi)發(fā)者手動(dòng)刷新或者輪詢更新，否則獲取的數(shù)據(jù)不會(huì)自動(dòng)更新。

這種底層模式對(duì)上層應(yīng)用的操作會(huì)有直觀的影響。

比如，下面是Windows 95中改變桌面外觀的配置項(xiàng)，用戶改變配置后，只有在點(diǎn)擊「OK」或「Apply」后，才能看到「改變配置后的效果」。

這一情況，有些類似前端框架普及前，開(kāi)發(fā)者手動(dòng)操作DOM的情況。

相比于Windows?，Mac OS X?則采用響應(yīng)式更新，在Mac OS中的很多配置項(xiàng)改變后用戶能夠立刻看到效果。

這一情況，類似開(kāi)發(fā)者使用前端框架后，「狀態(tài)變化」能夠自動(dòng)觸發(fā)「視圖更新」。

操作系統(tǒng)的演進(jìn)，對(duì)前端框架發(fā)展是有借鑒意義的。

后面的故事正如上面所說(shuō)，Mac OS X的發(fā)展方向是「為了更好的用戶體驗(yàn)，打磨各種細(xì)節(jié)」，而前端框架的發(fā)展方向是「更快」。

前端框架走歪了么？

?「React 并發(fā)特性」應(yīng)該是今年前端領(lǐng)域比較熱門(mén)的話題了。

但是，從社區(qū)關(guān)于「并發(fā)特性」的文章看，相比于「使用并發(fā)特性并從中獲益」，更多文章是關(guān)于「并發(fā)特性的科普，以及解釋他造成的影響」。

從這個(gè)角度看，「并發(fā)特性」似乎叫好不叫座。

如果從更廣的范圍考慮「用戶體驗(yàn)」，React可不可以有其他發(fā)展方向呢？

比如，當(dāng)前連續(xù)事件（Continuous Events?，指連續(xù)觸發(fā)的事件，比如鼠標(biāo)事件、滾動(dòng)事件）觸發(fā)的頻率、速度通常比 React重新渲染的速度要快，容易造成不好的用戶體驗(yàn)。

通常的解決方案是使用ref?。換句話說(shuō)，就是降級(jí)到手動(dòng)操作DOM。這里是不是有很大優(yōu)化空間呢？

除了React外，其他框架是不是也能從這個(gè)角度考慮發(fā)展方向呢？

你認(rèn)為前端框架的發(fā)展方向走歪了么？

參考資料

[1]get-in-zoomer-we-re-saving-react:https://acko.net/blog/get-in-zoomer-we-re-saving-react/。