最早的時候頁面是服務端渲染的，也就是 PHP、JSP 那些技術，服務端通過模版引擎填充數據，返回生成的 html，交給瀏覽器渲染。那時候表單會同步提交，服務端返回結果頁面的 html。

后來瀏覽器有了 ajax 技術，可以異步的請求，服務端返回 xml 或者 json。ajax 最早是基于 xml 的，這也是它名字的由來。因為 xml 多了很多沒必要的標簽，內容比較多，所以后來 json 流行開來。

網頁和服務端的數據交互變成了異步的，可以服務端返回 json 數據，瀏覽器里拼接 html，之后渲染（瀏覽器里面生成 dom 就等同于渲染）。頁面基本沒啥刷新的必要了，于是后來就逐漸演變出了單頁應用 SPA（single page application）。

早期開發頁面的時候就是基于瀏覽器的 dom api 操作 dom 來做渲染和交互，但是 dom api 比較啰嗦，而且當時瀏覽器的兼容性問題也比較麻煩，不同瀏覽器有不同的寫法。

為了簡化 dom 操作和更方便的兼容各種瀏覽器，出現了 jquery 并且迅速流行開來，那個時代 jquery 是如日中天的。

我一直習慣把網頁分為物理層和邏輯層，dom 就算是物理層，jquery 是操作 dom 的一系列工具函數，也是工作在物理層。

網頁做的事情基本就是拿到數據渲染 dom，并且數據改變之后更新 dom，這個流程是通用的，后來逐漸出現了 mvvm 框架，來自動把數據的變更映射到 dom，不再需要手動操作 dom。也就是 vue、react 等現代的前端框架。我把這一層叫做邏輯層。

前端框架除了提供了數據驅動視圖變化的功能以外，還支持了 dom 的邏輯劃分，可以把一部分 dom 封裝成組件，組件和組件之間相互組合，構成整個界面。物理層依然是 dom，只是實現了數據到 dom 的自動映射之后，我們只需要在邏輯層寫組件就可以了。

現在前端入門也不會再學物理層的操作 dom 的 jquery 了，而是直接從 vue、react 這種邏輯層的前端框架開始。

但是也不是說完全不需要 jquery，前端框架主要解決的是數據到 dom 的綁定，可以變化以后自動更新 dom。如果不需要更新，那么直接操作 dom 即可，比如各種活動頁，沒啥數據更新，用 jquery 操作 dom 還是很方便。

前端框架是 UI = f(state) 這種聲明式的思想，只需要聲明組件的視圖、組件的狀態數據、組件之間的依賴關系，那么狀態改變就會自動的更新 dom。而 jquery 那種直接操作 dom 的工具函數庫則是命令式的。

對于視圖的描述這件事 react 和 vue 用了不同的方案，react 是給 js 擴展了 jsx 的語法，由 babel 實現，可以在描述視圖的時候直接用 js 來寫邏輯，沒啥新語法。

而 vue 是實現了一套 template 的 DSL，引入了插值、指令、過濾器等模版語法，相對于 jsx 來說更簡潔，template 的編譯器由 vue 實現。

vue template 是受限制的，只能訪問 data，prop、method，可以靜態的分析和優化，而 react 的 jsx 因為直接是 js 的語法，動態邏輯比較多，沒法靜態的做分析和優化。

但是 vue template 也不全是好處，因為和 js 上下文割裂開來，引入 typescript 做類型推導的時候就比較困難，需要單獨把所有 prop、method、data 的類型聲明一遍才行。而 react 的 jsx 本來就是和 js 同一個上下文，結合 typescript 就很自然。

所以 vue template 和 react jsx 各有優缺點。

前端框架都是數據驅動視圖變化的，而這個數據分散在每個組件中，怎么在數據變化以后更新 dom 呢？

數據變化的檢測基本只有三種方式：watch、臟檢查、不檢查。

vue 就是基于數據的 watch 的，組件級別通過 Object.defineProperty 監聽對象屬性的變化，重寫數組的 api 監聽數組元素的變化，之后進行 dom 的更新。

angular 則是基于臟檢查，在每個可能改變數據的邏輯之后都對比下數據是否變了，變了的話就去更新 dom。

react 則是不檢查，不檢查難道每次都渲染全部的 dom 么？也不是，不檢查是因為不直接渲染到 dom，而是中間加了一層虛擬 dom，每次都渲染成這個虛擬 dom，然后 diff 下渲染出的虛擬 dom 是否變了，變了的話就去更新對應的 dom。

這就是前端框架的數據驅動視圖變化的三種思路。

vue 是組件級別的數據 watch，當組件內部監聽數據變化的地方特別多的時候，一次更新可能計算量特別大，計算量大了就可能會導致丟幀，也就是渲染的卡頓。所以 vue 的優化方式就是把大組件拆成小組件，這樣每個數據就不會有太多的 watcher 了。

react 并不監聽數據的變化，而是渲染出整個虛擬 dom，然后 diff。基于這種方案的優化方式就是對于不需要重新生成 vdom 的組件，通過 shouldComponentUpdate 來跳過渲染。

但是當應用的組件樹特別大的時候，只是 shouldComponentUpdate 跳過部分組件渲染，依然可能計算量特別大。計算量大了同樣可能導致渲染的卡頓，怎么辦呢？

樹的遍歷有深度優先和廣度優先兩種方式，組件樹的渲染就是深度優先的，一般是通過遞歸來做，但是如果能通過鏈表記錄下路徑，就可以變成循環。

變成了循環，那么就可以按照時間片分段，讓 vdom 的生成不再阻塞頁面渲染，這就像操作系統對多個進程的分時調度一樣。

這個通過把組件樹改成鏈表，把 vdom 的生成從遞歸改循環的功能就是 react fiber。

fiber 節點相對于之前的組件節點來說，沒有了 parent、children 這種屬性，多了 child、sibling、return 屬性。

通過 fiber 鏈表樹，優化了渲染的性能。

可以看到 vue 的性能優化和 react 的性能優化是不一樣的：

vue 是組件級別的數據監聽的方案，問題可能出現在一個屬性太多 watcher 的時候，所以優化思路就是大組件拆分成小組件，保證每個屬性不要有太多 watcher。

react 不監聽、不檢查數據變化，每次都渲染生成 vdom，然后進行 vdom 的對比，那么優化的思路就是 shouldComponentUpdate 來跳過部分組件的 render，而且 react 內部也做了組件樹的鏈表化（fiber）來把遞歸改成可打斷的渲染，按照時間片來逐漸生成整個 vdom。

組件之間難免要有邏輯的復用，react 和 vue 有不同的方案：

vue 的組件是 option 對象的方式，那么邏輯復用方式很自然可以想到通過對象屬性的 mixin，vue2 的組件內邏輯復用方案就是 mixin，但是 mixin 很難區分混入的屬性、方法的來源，比較亂，代碼維護性差。但也沒有更好的方案。

react 剛開始也是支持 mixin 的，但后來廢棄了。

react 的組件是 class 和 function 兩種形式，那么類似高階函數的高階組件（high order component）的方式就比較自然，也就是組件套組件，在父組件里面執行一部分邏輯，然后渲染子組件。

除了多加一層組件的 HOC 方式以外，沒有邏輯的部分可以直接把那部分 jsx 作為 props 傳入另一個組件來復用，也就是 render props。

HOC 和 render props 是 react 的 class 組件支持的兩種邏輯復用方案。

最開始的 function 組件是沒有狀態的，只是作為 class 組件渲染的輔助而存在。

但是 HOC 的邏輯復用方式最終導致了組件嵌套太深，而且 class 內部生命周期比較多，邏輯都放在一起導致了組件比較大。

怎么解決 class 組件嵌套深和組件大的問題呢？而且還不能引入破壞性的更新，不然下場可能會很慘。

于是 react 團隊就瞅準了 function 組件，能不能在 function 組件里面也支持 state，通過擴展一些 api 的方式來支持，也不是破壞性的更新。

function 組件要支持 state，那 state 存在哪里呢？

class 組件節點有 state，變成 fiber 節點之后依然有，function 組件本來就沒有 state，那么 fiber 節點中同樣也沒有。

那在 function 組件的 fiber 節點中加入 state 不就行了？

于是 react 就在 function 組件的 fiber 節點中加入了 memorizedState 屬性用來存儲數據，然后在 function 組件里面通過 api 來使用這些數據，這些 api 被叫做 hooks api。

因為是使用 fiber 節點上的數據，就把 api 命名為了 useXxx。

每個 hooks api 都要有自己存放數據的地方，怎么組織呢？有兩種方案，一種是 map，一種是數組。

用 map 的話那么要 hooks api 要指定 key，按照 key 來存取 fiber 節點中的數據。

用數組的話順序不能變，所以 hooks api 不能出現在 if 等邏輯塊中，只能在頂層。

為了簡化使用， hooks 最終使用了數組的方式。當然，實現起來用的是鏈表。

每個 hooks api 取對應的 fiber.memoriedState 中的數據來用。

hooks api 可以分為 3 類：

第一類是數據類的：

• useState：在 fiber.memoriedState 的對應元素中存放數據
• useMemo：在 fiber.memoriedState 的對應元素中存放數據，值是緩存的函數計算的結果，在 state 變化后重新計算值
• useCallback：在 fiber.memoriedState 的對應元素中存放數據，值是函數，在 state 變化后重新執行函數，是 useMemo 在值為函數的場景下的簡化 api，比如 useCallback(fn, [a,b]) 相當于 useMemo(() => fn, [a, b])
• useReducer：在 fiber.memoriedState 的對應元素中存放數據，值為 reducer 返回的結果，可以通過 action 來觸發值的變更
• useRef：在 fiber.memoriedState 的對應元素中存放數據，值為 {current: 具體值} 的形式，因為對象不變，只是 current 屬性變了，所以不會修改。

useState 是存儲值最簡單的方式，useMemo 是基于 state 執行函數并且緩存結果，相當于 vue 的 getter，useCallback 是一種針對值為函數的情況的簡化，useReducer 是通過 action 來觸發值的修改。useRef 包了一層對象，每次對比都是同一個，所以可以放一些不變的數據。

不管形式怎么樣，這些 hooks 的 api 的作用都是返回值的。

第二類是邏輯類的：

• useEffect：異步執行函數，當依賴 state 變化之后會再次執行，當組件銷毀的時候會調用返回的清理函數
• useLayoutEffect：在渲染完成后同步執行函數，可以拿到 dom

這兩個 hooks api 都是用于執行邏輯的，不需要等渲染完的邏輯都可以放到 useEffect 里。

第三類是 ref 轉發專用的：

數據可以通過各種方案共享，但是 dom 元素這種就得通過 ref 轉發了，所謂的 ref 轉發就是在父組件創建 ref，然后子組件把元素傳過去。傳過去之前想做一些修改，就可以用 useImperativeHandle 來改。

通過這 3 類 hooks api，以及之后會添加的更多 hooks api ，函數組件里面也能做 state 的存儲，也能在一些階段執行一段邏輯，是可以替代 class 組件的方案了。

而且更重要的是，hooks api 是傳遞參數的函數調用的形式，可以對 hooks api 進一步封裝成功能更強大的函數，也就是自定義 hooks。通過這種方式就可以做跨組件的邏輯復用了。

再回頭看一下最開始要解決的 class 組件嵌套過深和組件太大的問題，通過 hooks 都能解決：

• 邏輯擴展不需要嵌套 hoc 了，多調用一個自定義的 hooks 就行
• 組件的邏輯也不用都寫在 class 里了，完全可以抽離成不同的 hooks

react 通過 function 組件的 hooks api 解決了 class 組件的邏輯復用方案的問題。（fiber 是解決性能問題的，而 hooks 是解決邏輯復用問題的）

vue2 中是通過 mixin 的方式來復用邏輯的，也有組件太大的問題，在 vue3 中也可以通過類似的思路來解決。

為了體驗和原生更接近，現在基本都是不刷新頁面的單頁應用，都是從服務端取數據然后驅動 dom 變化的 瀏覽器渲染(csr)方案。但對于一些低端機，仍然需要服務端渲染(ssr)的方案。

但不能回到 jsp、php 時代的那種模版引擎服務端渲染了，而是要基于同一個組件樹，把它渲染成字符串。服務端渲染和瀏覽器渲染都用同樣的組件代碼，這就是同構的方案。

技術從出現到完善到連帶的周邊生態的完善是一個輪回，從最開始服務端渲染，到了后來的客戶端渲染，然后出現了邏輯層的組件方案，最后又要基于組件方案重新實現服務端渲染。

其實物理層的東西一直都沒變，只是邏輯層不斷的一層添加又一層，目的都是為了提高生產效率，降低開發成本，保證質量，這也是技術發展的趨勢。