一個新視角：前端框架們都卷錯方向了？

大家好，我卡頌。

近幾年，前端領域出現了很多新框架，比如Svelte、 Solid.js、Astro、Qwik等。

伴隨他們出現的，還有很多高大上的新概念 —— 執行時/編譯時框架、Islands架構、Selective Hydration......

這些概念的本質，就是通過各種方式，讓頁面更快。

這裡的快主要包括兩方面：

• 讓HTML載入更快（一眾和SSR相關的概念與此有關，比如Islands架構）

• 更快響應互動（一眾採用細粒度更新的框架與此有關，比如Vue、Solid.js）

但是，快就是評價Web未來發展方向的唯一標準麼？

一位有32年開發經驗的老程式設計師在他的博文get-in-zoomer-we-re-saving-react中提出了不同的觀點。

本文是對該博文的部分解讀。

歡迎加入人類高質量前端框架研究群，帶飛

對應用來說，什麼才是重要的？

上面提到，現在前端框架的新特性，是通過各種方式，讓頁面更快。

這裡的主語是頁面而不是應用。

事實上，雖然開發者經常談論Web App，但大部分開發者開發的，只能稱為頁面。

頁面與應用的一大差別，就是互動體驗的差異。

如果一個頁面中某些互動類似IOS原生應用，我們會說這個頁面互動做的很棒。

所以，雖然速度快是互動體驗中重要的一環，但絕不是全部，還有大量細節值得考慮。

以業界使用者體驗的標杆Mac OS舉例：

• 在Mac OS中，開啟應用的狀態列時，按住command + option之類的快捷鍵能夠開啟進階功能：

• 撤回（command + z）操作的結果對各種操作目標都是符合預期的（不管目標是文字還是檔案等）

• 富文字內容的複製、貼上與富文字內容通過拖拽的表現一致

做過富文字編輯器的同學應該能感受到上述功能的難度

上述這些符合預期的細節背後，是一套響應式系統。

響應式系統

Mac OS X是第一款聲稱自己為響應式的作業系統。在此之前，業界的效仿物件是Windows作業系統。

在Windows中，資料是非響應式的。除非開發者手動重新整理或者輪詢更新，否則獲取的資料不會自動更新。

這種底層模式對上層應用的操作會有直觀的影響。

比如，下面是Windows 95中改變桌面外觀的配置項，使用者改變配置後，只有在點選OK或Apply後，才能看到改變配置後的效果。

這一情況，有些類似前端框架普及前，開發者手動操作DOM的情況。

相比於Windows，Mac OS X則採用響應式更新，在Mac OS中的很多配置項改變後用戶能夠立刻看到效果。

這一情況，類似開發者使用前端框架後，狀態變化能夠自動觸發檢視更新。

作業系統的演進，對前端框架發展是有借鑑意義的。

後面的故事正如上面所說，Mac OS X的發展方向是為了更好的使用者體驗，打磨各種細節，而前端框架的發展方向是更快。

前端框架走歪了麼？

React 併發特性應該是今年前端領域比較熱門的話題了。

但是，從社群關於併發特性的文章看，相比於使用併發特性並從中獲益，更多文章是關於併發特性的科普，以及解釋他造成的影響。

從這個角度看，併發特性似乎叫好不叫座。

如果從更廣的範圍考慮使用者體驗，React可不可以有其他發展方向呢？

比如，當前連續事件（Continuous Events，指連續觸發的事件，比如滑鼠事件、滾動事件）觸發的頻率、速度通常比 React重新渲染的速度要快，容易造成不好的使用者體驗。

通常的解決方案是使用ref。換句話說，就是降級到手動操作DOM。這裡是不是有很大優化空間呢？

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

你認為前端框架的發展方向走歪了麼？