一個新視角:前端框架們都卷錯方向了?
大家好,我卡頌。
近幾年,前端領域出現(xiàn)了很多新框架,比如??Svelte?
??、 ??Solid.js?
??、??Astro?
??、??Qwik?
?等。
伴隨他們出現(xiàn)的,還有很多「高大上」的新概念 —— 「運行時/編譯時框架」、「Islands架構」、「Selective Hydration」......
這些概念的本質,就是「通過各種方式,讓頁面更快」。
這里的「快」主要包括兩方面:
- 讓HTML加載更快(一眾和SSR相關的概念與此有關,比如「Islands架構」)
- 更快響應交互(一眾采用「細粒度更新」的框架與此有關,比如Vue、Solid.js)
但是,「快」就是評價Web未來發(fā)展方向的唯一標準么?
一位有32年開發(fā)經(jīng)驗的老程序員在他的博文[1]中提出了不同的觀點。
本文是對該博文的部分解讀。
對應用來說,什么才是重要的?
上面提到,現(xiàn)在前端框架的新特性,是「通過各種方式,讓頁面更快」。
這里的主語是「頁面」而不是「應用」。
事實上,雖然開發(fā)者經(jīng)常談論Web App,但大部分開發(fā)者開發(fā)的,只能稱為頁面。
頁面與應用的一大差別,就是「交互體驗的差異」。
如果一個頁面中某些交互類似IOS原生應用,我們會說這個頁面交互做的很棒。
所以,雖然「速度快」是交互體驗中重要的一環(huán),但絕不是全部,還有大量細節(jié)值得考慮。
以業(yè)界用戶體驗的標桿Mac OS舉例:
- 在Mac OS中,打開應用的狀態(tài)欄時,按住「command + option」之類的快捷鍵能夠開啟進階功能:
按住command + option前
按住command + option后
- 撤回(command + z)操作的結果對各種操作目標都是符合預期的(不管目標是文本還是文件等)。
- 富文本內容的復制、粘貼與富文本內容通過拖拽的表現(xiàn)一致。
做過富文本編輯器的同學應該能感受到上述功能的難度
上述這些「符合預期」的細節(jié)背后,是一套「響應式系統(tǒng)」。
響應式系統(tǒng)
Mac OS X?是第一款聲稱自己為「響應式」的操作系統(tǒng)。在此之前,業(yè)界的效仿對象是Windows操作系統(tǒng)。
在Windows中,數(shù)據(jù)是「非響應式」的。除非開發(fā)者手動刷新或者輪詢更新,否則獲取的數(shù)據(jù)不會自動更新。
這種底層模式對上層應用的操作會有直觀的影響。
比如,下面是Windows 95中改變桌面外觀的配置項,用戶改變配置后,只有在點擊「OK」或「Apply」后,才能看到「改變配置后的效果」。
這一情況,有些類似前端框架普及前,開發(fā)者手動操作DOM的情況。
相比于Windows?,Mac OS X?則采用響應式更新,在Mac OS中的很多配置項改變后用戶能夠立刻看到效果。
這一情況,類似開發(fā)者使用前端框架后,「狀態(tài)變化」能夠自動觸發(fā)「視圖更新」。
操作系統(tǒng)的演進,對前端框架發(fā)展是有借鑒意義的。
后面的故事正如上面所說,Mac OS X的發(fā)展方向是「為了更好的用戶體驗,打磨各種細節(jié)」,而前端框架的發(fā)展方向是「更快」。
前端框架走歪了么?
?「React 并發(fā)特性」應該是今年前端領域比較熱門的話題了。
但是,從社區(qū)關于「并發(fā)特性」的文章看,相比于「使用并發(fā)特性并從中獲益」,更多文章是關于「并發(fā)特性的科普,以及解釋他造成的影響」。
從這個角度看,「并發(fā)特性」似乎叫好不叫座。
如果從更廣的范圍考慮「用戶體驗」,React可不可以有其他發(fā)展方向呢?
比如,當前連續(xù)事件(Continuous Events?,指連續(xù)觸發(fā)的事件,比如鼠標事件、滾動事件)觸發(fā)的頻率、速度通常比 React重新渲染的速度要快,容易造成不好的用戶體驗。
通常的解決方案是使用ref?。換句話說,就是降級到手動操作DOM。這里是不是有很大優(yōu)化空間呢?
除了React外,其他框架是不是也能從這個角度考慮發(fā)展方向呢?
你認為前端框架的發(fā)展方向走歪了么?
參考資料
[1]get-in-zoomer-we-re-saving-react:https://acko.net/blog/get-in-zoomer-we-re-saving-react/。