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

語言: CN / TW / HK

大家好,我卡頌。

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

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

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

這裡的「快」主要包括兩方面:

  • 讓HTML載入更快(一眾和SSR相關的概念與此有關,比如「Islands架構」)
  • 更快響應互動(一眾採用「細粒度更新」的框架與此有關,比如Vue、Solid.js)

但是,「快」就是評價Web未來發展方向的唯一標準麼?

一位有32年開發經驗的老程式設計師在他的博文[1]中提出了不同的觀點。

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

對應用來說,什麼才是重要的?

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

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

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

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

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

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

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

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

按住command + option前

按住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外,其他框架是不是也能從這個角度考慮發展方向呢?

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

參考資料

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