京東雲開發者｜關于“React 和 Vue 該用哪個”我真的栓Q

一、前言：我全都要

面對當今前端界兩座大山一樣的主流架構，React 和 Vue，相信很多小夥伴都或多或少都産生過這樣疑問，而這樣的問題也往往很讓人頭疼和猶豫不決：

1. 業務場景中是不是團隊用什麼我就用什麼？
2. 如果選擇了其中一個使用，那為什麼不用另一個？
3. 這兩個架構各有什麼優點和無法解決的問題？
4. 最新版本的 Vue3 已經出了一段時間了，我要不要做組内第一個吃螃蟹的勇士？
5. 我該依據什麼樣的因素決定使用哪個技術棧？

以上問題如果想不明白，很容易産生一個 “算了不想了真麻煩，還是随大流好了，至少不會出錯” 的答案，其實種種疑問都指向了一個終極問題，那就是關于技術棧的選型。

而技術棧選擇的合适與否，往往對項目後續的開發有着極大的影響，甚至關系到業務落地的效率和效果。僅僅掌握業務邏輯的開發，已經完全不能滿足個人發展了， 就好比一門武林絕學，招式用的再熟，也需要心法輔佐，是以也就引出了本文的主題：

1. 旨在幫助那些對技術棧選擇困難症的同學，并對 React 和 Vue 産生一定的認知
2. 同時也适合那些隻了解單一技術棧的小夥伴，可以拓展一下對不同架構的了解

二、正文：到底要啥

本文不會從正面回答上面列出的問題，技術棧的選擇往往要依據現實情況從多方面考慮，是以我也将從以下幾個方面分别闡述觀點，各位讀者可以結合自身情況和以下觀點，決定 React 和 Vue 到底要用哪一個。而其實關于技術選型，很容易代入自己的主觀意識，“好和壞”在同樣優秀的架構面前更像是一種自我感受，但筆者會盡量從客觀的角度去闡述，如果過程中觀點出現沖突或有誤，歡迎與我交流、指正。

• 選型對象說明
• 團隊的适用性
• 相容性要求
• 使用層面對比
• 周邊配套
• 跨端處理
• 設計思路
• 性能對比
• 心智模型
• 社群生态
• 開源代碼許可協定

1. 選型對象說明

對比對象：React（hooks 版本）、Vue2、Vue3

關于對比對象的選擇：

• React 有函數式元件的和類元件兩種寫法，鑒于 class 寫法較老，且這種寫法不利于建構工具的 Tree-shaking，可能導緻建構産物體積增加，而函數式元件的 hooks 寫法更符合未來的潮流， 是以類元件在此也不做詳細的介紹，隻選取函數式元件寫法的 React 作為對比對象。
• Vue2 相較 Vue3 版本而言牢牢占據着大部分 Vue開發者的視野，但是因為 Vue 官方已經把 Vue3 作為預設的版本，是以在此同時把 Vue2 和 Vue3 作為對比對象。
• 對比的内容不會涉及到具體的某個 API 的實作，也不會講解大篇幅幹澀的源碼，過于詳細的内容不是本文的重點，作為技術選型要從整體出發去考慮。

2. 團隊的适用性

在這方面，其實選哪個架構取決于團隊全體成員

• 曆史原因：如果你是以開發者的身份剛入職到一個新的環境，并且接手的是一個成熟的項目，處于正常疊代或者維護周期，那千萬不要想着颠覆團隊已有技術棧，技術棧切換就相當于重構。

  而這種重構面臨的首要影響就是投入和産出不成正比，相信文章的讀者大多也都是撲在各個業務一線上，對業務方來說，采用什麼樣的技術去實作他們并不關心，并且切換技術棧帶來的風險、開發人力和測試回歸的成本都難以評估，除非帶來巨大價值，否則這也是與我們合作的上下遊都難以接受的。

• 團隊習慣：如果你是項目負責人，在抛開對架構本身進行對比的同時，要考慮的是團隊成員對技術棧的熟悉程度，在大多數人都對某一項技術棧熟悉、而對另一項技術了解不深的情況下，那更為熟悉的技術棧帶來的人效和産出品質，顯然能幫助業務快速驗證和試錯。

注意：不熟悉某項技術，絕不能成為不使用這項技術的托詞，從個人提升的角度考慮，學習新的技術棧可以幫助我們擴充思路和視野，如果要做的新項目周期不緊張，也預留了充足的時間，那麼新的技術顯然可以作為備選項之一。

3. 相容性要求

• PC端：React 和 Vue 均不支援 IE8，對于個别浏覽器相容模式使用 IE 核心也可能是不支援的，具體要看使用的核心版本（IE 浏覽器簡直是前端界的噩夢），其他浏覽器下可以放心大膽地使用了。
• H5端：React 和 Vue 2.x 均能使用。

注意：在移動端對于想要嘗鮮 Vue 3.x 版本的同學來說要關注一下，Vue 3.x 依賴收集是使用 Proxy 這個 API，而 Proxy 在 IOS 端最低支援 IOS10 版本，并且由于這個 API 具備更底層的對象監聽能力，導緻 polyfill 無法完全相容，已實作的 polyfill 都是基于 Object.defineProperty，并不能完整支援 Proxy 所有特性（比如數組長度的監測），是以如果業務環境對 IOS9 有相容需求的情況下，就不要嘗試了。

4.使用層面對比

架構引入

• React 和 Vue 都是漸進式架構，支援 script 标簽直接使用，也支援在工程中通過子產品化方式引入使用。

Jsx VS Template

• React：

  采用的 Jsx 在寫法上更為靈活多變，屬于在 Js 中增加了 HTML 文法，元件的實作思路是 All in Js，開發過程中擁有 Js 完整的生态。同時開發工具對 JSX 的支援相比于現有可用的其他 Vue 模闆也比較先進 (比如，linting、類型檢查、編輯器的自動完成)。

• Vue：

  整體思路是 Template 模闆文法，跟 Jsx 相比，它是在 HTML 中增加了對部分 Js 文法的支援，在靈活度上不如 Jsx，本質是模闆文法無法窮舉所有 Js 能力，是以筆者認為 Vue 内部使用的 slot、directive 等，也恰恰是對模闆文法不夠靈活所做出的一種補充，使模闆文法也能完成跟 Jsx 同樣的事情。

  模闆文法也有優點，它更接近原生 HTML，對于新手上手更友好，并且在 Vue3 中，它從模版層面進行靜态分析，對靜态模版做标記，進而提升 diff 的效率。

  值得一提的是，與 React 一樣，Vue 在技術上也支援 render 函數和 Jsx，但隻是不是預設的而已。

那麼你可能會有疑問，為什麼 Template 不去适配所有的 Js 文法？這裡舉一個例子：Taro。

Taro1.x 和 Taro2.x 采用了窮舉所有 Jsx 文法的方式，去生成不同平台的代碼，導緻每次 Jsx 或 Js 文法有更新，這兩個版本的 Taro 編譯器都要同步去做适配，這是一種重編譯時的方案，對 Jsx 的支援其實非常痛苦，是以 Taro3 索性采取了重運作時、輕編譯時的重構，以獲得編譯器對 Jsx 更有好的支援。

并且還有另一個原因是，我們假如 Template 支援了所有 Js 能力，那麼勢必又導緻了 Template 文法變得複雜，也可能和原本統一的 Ecma 規範割裂（層出不窮的小程式就是一個典型的例子，相當于規範之中又出規範，生态之外再造生态），造成了學習成本增加和沉重的編譯器。

• 共性也是有的，都是 DSL，對底層而言，雖然兩者采用了不一樣的方式實作，但最終都會被編譯為渲染函數去執行。
• 下圖是 Jsx 文法示例：

• 下圖是 Template 文法示例：

SFC

• HTML：React 是 Jsx，Vue 是預設的 Template，在這裡不在贅述差別，同時需要指出的是，Vue3 相較 Vue2 而言，Template 下可以允許存在多個根節點，可以減少一些不必要的 DOM 層級。
• JS：React 元件本身就是 JS 檔案，形式采用函數元件和類元件，程式設計範式上更貼近面向對象 + 官方推崇的函數式。Vue2 元件是 Options Api，通過一個個配置項去實作生命周期、狀态聲明和邏輯開發。Vue3 對于部分邏輯處理和 Vue2 有很大差別，setup 模式下，已經和 React 越來越趨同了，程式設計範式是面向過程 + 函數式，官方命名為 Composition Api，可以使同一個功能邏輯更加集中。
• CSS：React 的 CSS 使用方式是直接通過 Import 導入，Vue 檔案中有專門處理樣式的 Style 标簽，值得一提的是，Vue3 内置狀态驅動的動态 CSS，詳細可檢視官方文檔（點選檢視）。
• 其他思考：React 的函數式元件和 Vue3 Composition Api，在 ESM 子產品規範下對 Tree-shaking 更友好，更容易減少建構體積。

元件使用

• React 元件僅需引入即可使用。
• Vue 的元件引入後需要全局或局部注冊，且元件内的 Props 的要顯式聲明。

邏輯複用

• React 的複用主要展現在高階元件、render props 以及 hooks，但是也有他們對應的不足。高階元件層級過深時容易帶來 props 的命名沖突、來源不明确的問題，并且額外的元件執行個體會有更多的記憶體消耗。hooks 的引入，使 React 的邏輯抽離更容易，完全修複了命名沖突，來源準确，且無額外開銷，可以貫徹函數式程式設計的理念。但是與此同時，因為 hooks 中可能保留着元件狀态，也意味着每次 React 的更新，如果不進行手動優化，不論前後資料是否有變化，每個 hook 都會重新執行，這也是底層架構上額外帶來的問題。
• Vue 的元件複用主要是是用 Mixin、Extend、插槽和 Vue3 的 Function API。Mixin：它和 React 的高階元件帶來的問題十分類似，響應式資料命名沖突，以及邏輯來源不明确。插槽：主要功能點是元件複用，它解決了資料命名沖突的問題，同時資料來源準确，但是也存在着額外元件執行個體帶來的記憶體消耗Function API：目前看來是較為優秀的一種邏輯複用方式，沒有以上列出的所有問題，雖然和 React 的 hooks 十分相像，但是本質不同，Vue 可以追蹤到資料變化，也僅在元件執行個體化時執行一次。

樣式隔離方案

• React：CSS moduleCSS in JSBEM 命名規範
• Vue：官方支援 Style scopedBEM 命名規範

TS支援

• React 本身就是 Js 和 Jsx，并且 TS 專門開了後門給做了支援（Jsx 其實一開始沒有類型支援，Tsx 的開發體驗完全來自于 TS 專門針對 Jsx 制定的一整套推導機制），是以 Tsx 的類型支援也很完善。
• Vue2.x 來自尤雨溪本人的回答是“因為當初 API 的設計根本就沒有考慮類型系統”，2.x 跟 TS 的整合需要借助 vue-class-component 使用類元件進行開發，是以目前 2.x 版本的 Vue 對 TS 的支援度較 React 仍有差距，但是最近随着 Vue2.7 的釋出，可以使 Vue2.x 用上大部分 Vue3 的寫法，也使 Vue2.x 就具備了相容 TS 的能力。
• Vue3，根據來自官方的建議，IDE 支援需用 <script setup lang="ts"> + vscode + volar，一樣能獲得非常好的 TS 體驗。

文檔體驗（這裡僅指中文文檔）

• React：中規中距，案例仍然不夠豐富，對于一些問題的答案需要借助社群，好在社群足夠強大，屬于疑難雜症的問題也能找到解決方案。
• Vue：文檔體驗十分優秀且全面，介紹詳細，幾乎各種疑問均能找到答案。

5.周邊配套

React

• 路由管理
• React-router 實作了核心路由功能。React-router-dom 基于 React-router 開發，加入了在浏覽器運作環境下的一些功能，如使用 Link 元件在浏覽器中會渲染一個 a 标簽，也支援 History 和 Hash 路由模式。React-router-native 同樣基于 React-router 開發，主要是內建了 React-native 運作環境下的功能。
• 狀态管理

• Redux 基礎的狀态管理庫，引入了中間件，中間件位于視圖層發出 action 後，到 reducer 之前觸發，在中間件中可以執行比如日志列印、異步請求等操作。

  原流程：view -> action -> reducer -> store

  中間件流程：view -> action -> middleware -> reducer -> store

• React-Redux 是 Redux 的插件庫，用來簡化 Redux。
• Redux-thunk 用來處理異步的中間件。
• Redux-saga 内部基于 generator 實作，用于管理 Redux 應用異步操作的中間件，與 thunk 不同點在于：thunk 是在 action 建立時調用，saga 是在應用啟動時調用。在 saga 中，任務都是通過 yield Effects 來完成的。
• Mobx 不同于 Redux 狀态管理方案，使用相對簡單，是以資料驅動視圖，通過資料綁定，隻修改資料本身即可實作視圖的更新。
• Vue
• 路由管理Vue router：官方支援
• 狀态管理Vuex：官方支援

6. 跨端處理

React

• App：

  在跨 App 界的一哥是 React Native，以下簡稱 RN，因為筆者沒有親自體驗過，是以不做過多闡述，但是鑒于 RN 是2015年4月問世，時間不短，并且也有足夠的團隊使用，目前看來在前端跨端的領域成熟度已經相當高了。

• 小程式：

  對 React 支援度最好的當然是 Taro 了，一直在持續疊代中，也有來自京東凹凸實驗室的背書，擁有較為穩定的産品和活躍社群，開發者可以大膽嘗試，在最近疊代的 Taro3 裡也添加了對 Vue3 的支援。

Vue

• App：

  的跨端嘗試中沒有占據絕對地位的架構，Weex 火過一陣，但是近些年熱度下降，并且在 Apache Incubator 也已退休，雖然有阿裡的背書，但是随着參與者減少，加上也不斷聽說阿裡内部逐漸放棄 Weex 的傳言，Github倉庫最近一個更新也是1年前，前景未知，不推薦嘗試。

  Vue 在最新的官方文檔中推薦的跨端方案是 NativeScript 和 Capacitor，感興趣的小夥伴可以自行檢視。

• 小程式：

  一種較為流行的跨端方案是 Uni-app，在相容多端小程式上有較好的體驗，對 Vue2 和 Vue3 有着天然友好的支援度，并且依照評測也提供着非常不多的性能（評測連結（點選檢視）），文檔體驗着實是一言難盡……同時也支援 App 應用的開發。

  另一種跨端方式是 Mpvue，來自美團，從 Github 的倉庫看已經很久未曾更新，也就不做推薦了。

• 多說幾句

  在這裡還要多啰嗦一下關于架構的跨端的個人了解，架構如果想跨端，那麼在設計之初就要做核心與平台分離的設計，虛拟 DOM 就是一個非常典型的例子，它可以存儲所有與 UI 的所有資訊和互動邏輯，而在它上層與平台強相關的部分負責具體平台的邏輯實作，這也是典型的分層設計。

7. 設計思路

• React 推崇的是單向資料流（但是也提供了方法進行雙向改變），是資料不可變性，不可直接改變資料本身，而是通過 hooks 或 setState 更新資料。

  每次更新調用渲染函數從根節點生成新的虛拟 DOM 對比 舊虛拟 DOM，找到改變位置後進行 UI 的重渲染，這其中使用了基于連結清單資料結構的 Fiber 架構，在每幀渲染周期内的空閑時間進行 Diff 過程，具備可中斷和可恢複的特性，以這種時間切片的方式不會阻塞主線程，以便執行更高優先級的任務，防止頁面卡頓。

  更新流程如下圖（沒有畫出具體細節，隻包含基本流程）：

• Vue 是借助 ES6 的 API 攔截資料操作，分别在資料讀取、設定階段進行依賴的收集和通知，資料的依賴其實是一個個 Watcher 對象（Watcher 可能是元件、計算屬性、或者 Watch方法）。如果 Watcher 是元件的情況，則再調用元件的 render 函數生成虛拟DOM ，與舊虛拟 DOM 做對比，進行更細粒度的 UI 更新。在這裡借助依賴收集和局部的 DOM Diff，平衡了全量 DOM Diff 帶來的性能影響。

  更新機制如下圖（來自 Vue 官網）：

8. 性能對比

對比說明

• 抛開場景談性能，就像抛開劑量談毒性，全是瞎扯 ，是以本章節性能對比的資料皆有據可查，對比僅覆寫了一些常見場景，但未能覆寫全部場景：
• 架構測試用例倉庫（點選檢視），截止到2022年6月23日，已有 4.6k Star，
• 對比資料（點選檢視），可根據條件篩選架構對比的結果
• 測試中的對比對象：React v18.0.0 和 Vue v3.2.37，不包含舊版本架構，本着架構更新帶來性能提升的正常認知（反優化的案例也不是沒有，但不在這做考慮），本章節預設最新版本的 React 和 Vue 在各自曆史版本中擁有着最優性能。
• 測試使用裝置配置：i7-8750H, 64 GB RAM, Fedora 36 (Linux 5.17.3, mitigations=off, Wayland)
• 測試使用浏覽器：Chrome 102.0.5005.61 (64-bit)
• 其他：本章節的資料對比，是對已有結果的總結

對比内容

1）持續時間，這裡進行的主要是資料量較大的清單操作，對比次元為：

• 建立清單
• 替換所有行
• 局部更新
• 選擇行
• 交換行
• 删除行
• 建立多行
• 追加多行

• 删除多行

  結論：可以看到 Vue 在此場景中近乎完勝，尤其是交換行的情況下，Vue 更是大幅度領先。

  結果可檢視下圖，綠色表示操作所需時間更短，紅色表示操作所需時間長。

  vanillajs 那一列指的是原生 js 下的性能資料。

2）啟動名額，主要從以下幾個方面對比：

• 加載時長：主要名額是 TTI（Time To Interactive），指從頁面開始加載到頁面可進行互動的時長，TTI 值越小，代表使用者可以更早地操作頁面，體驗就越好
• 主線程工作時間：包含樣式、布局、執行邏輯等
• 網絡傳輸位元組數：指加載頁面中所有資源的成本
• 結果如下圖，仍然是 Vue 的成績較為優秀：

3）以 MB 為機關的記憶體配置設定，對比次元為：

• 頁面加載後的記憶體使用情況
• 運作記憶體，添加 1000 行後的記憶體使用情況
• 每 10 行點選更新 5 次後的記憶體使用情況
• 單擊建立 1000 行 5 次後的記憶體使用情況
• 建立和清除 1000 行 5 次後的記憶體使用情況
• 結果如下圖，Vue 依然勝出了：

• 4）聊些對比之外的話

  以上在運作時的對比都是以1000行資料為基準做參考，問各位小夥伴一個問題，如果資料量更龐大呢，5w行或者10w行，再或者50w行？資料會有變化嗎？各位可以再思考一下這個問題：那僅僅從以資料作為評測标準又是否可行呢？

  其實筆者不以為然，雖然 React 的資料落于下風，但是從 React 的 Fiber 架構上看，尤其涉及到超過一定數量級的虛拟 DOM 對比上，React 是具有優勢的，此架構下的 Diff 不會阻塞主線程，使用者對 UI 界面依然有控制權，雖然頁面資料沒有更新，但是對于使用者的感覺是相對友好的。

  是以筆者認為以下對比資料具有參考性，但并非是決定性的，在架構對比上還是希望各位小夥伴有多方面更理性的思考 。

9. 心智模型

關于心智負擔，有觀點認為 React 重，也有觀點認為 Vue 重，而筆者認為都有道理，原因是兩方的關注點不同。

說 React 重，可以從兩方面闡述：

• 亂花漸欲迷人眼：React 官方隻維護了的核心庫，對于狀态管理、CSS隔離方案等均交給了社群，這樣做可以很大程度上提升開發者的參與度，也很容易誕生一些優秀的想法，造成社群内俨然就是一副百花齊放的繁榮景象，但是這也恰好是缺陷所在，在大型的 React 項目中，一旦缺少強約定，甚至能出現好幾種狀态管理和 Fetch 庫，使開發者對項目維護、工具選擇都出現困擾，于是“百花争鳴”也很容易變成“亂花漸欲迷人眼”了。

  而 Vue 則提供了核心庫以外的狀态管理、路由等，官方的庫品質也有所保障，開發者隻要無腦使用即可。

• 在項目優化中，由于 React 的更新特性是自根節點開始不斷遞歸對比虛拟dom去查找變化，如果不進行手動優化，那麼将導緻每層元件都會重新調用render，在大型項目中可能就是性能災難，是以 React 官方提供了很多專門用于優化的 API，比如 shouldComponentUpdate、PureComponent、React.memo 等，緻使在日常工作中，開發者在思考業務邏輯的同時，還要考慮性能優化，無法專注于業務本身。

  而 Vue 則因為天生具有依賴收集的優勢，對于資料的變化更敏感和準确，開發者即使不刻意關注優化，Vue 也能提供給你不錯的性能。

說 Vue 重的，其實大多糾結在 API 數量，需要記憶的東西多，并且如果使用了 Vue3，那就又會發現 Vue3 裡不論是 setup 寫法，還是 API 的更新，都有了翻天覆地的變化，于是發現要記憶的東西就更多了 :cold_sweat:

但是這幾點對于有經驗的熟練架構使用者來說，常用的 API 其實很固定，也往往就是那麼幾個，對于新入門的小夥伴，千萬不要産生勸退心理 :grimacing:

10. 社群生态

• 全球開發者使用架構占比調查，資料來源于 Stackoverflow 的 58,743 名受訪者，截圖中未完全列出所有看架構的排名，點選連結檢視，React 相較 Vue 牢牢占據着第二把交椅。

截止到 2022年6月23日 的一些資料

• npm 周下載下傳量：React：15,764,543 次Vue：3,279,362 次
• 在 Stackoverflow 上關于 #reactjs 标簽的問題讨論有 396,378 個，而關于 #vue.js 的有 94709 個
• 在 Github 上，Vue 的 Star 數為 197K，已經超過 React 的 190K
• 另一方面，通過來自 similartech 的資料顯示，React 被應用在了 1,256,598 個網站中，并仍在以每月 0.59% 的速率增長，而使用 Vue 的網站有 296,047 個，每月增長速率為 0.87%。

11. 開源代碼許可協定

也叫軟體許可證，具體解釋可以檢視維基百科，下面說重點。

• React 是 Facebook 的開源項目，Facebook 在2016年11月強化了 BSD 許可證和專利許可證的概念，在對許可證書授權方和被授權方而言，存在待遇上的不對等性，這就帶來一個很關鍵的風險點：使用 React 的公司和 Facebook 一旦存在業務競争，React 将成為 Facebook 獲得訴訟勝利重要籌碼，這無形之中将給競争公司帶來法務風險，雖然 React 後來把開源協定改成了 MIT，但是前車之鑒，在某些重大項目的技術棧選擇上，尤其在目前國際環境的鬥争中還是要慎重考慮，并充分告知本公司潛在的風險。
• Vue 是由國人尤雨溪開發，軟體協定為 MIT，目前在國内起碼暢快使用是沒問題的。
• 關于開源協定的解釋可以檢視百度百科

三、總結：做個了斷

終于到結尾了，關于 React 和 Vue 的選型，我們來做個總（liǎo）結（duàn）吧。

1. 在選型前，首先是要考慮曆史因素和團隊現狀，切換技術棧的前提是不要顯著的增加上下遊合作方的時間成本。
2. 充分考慮架構的相容性，如果不滿足業務需求，再優秀也要 pass。
3. 對于新手來說，React 過于靈活，雖然常用 API 不多，但是裡面有很多設計模式和概念，在具備一定規模的項目中，新手的學習曲線一開始會比較陡，并且需要代碼手動優化，同時龐大的社群中有層出不窮的優秀架構，但是在同類型庫的選擇上也會相對吃力，是以不推薦新手使用。但是對于具備幾年經驗的開發者來說，React 的靈活也恰恰是優勢，再結合各種設計模式，很容易使項目更具創造性，對于維護具備一定規模的項目很有益處，這也真正能展現開發者的程式設計能力。
4. 而 Vue 則恰恰相反，對新手友好，SFC 中 HTML、script、style 互相隔離的方式更符合傳統的前端開發邏輯，Vue 也已提供了基本的優化，且周邊架構的選型也不需要過多關注。

5. 關于是否适合大型項目，有人說 Vue 不适合大型項目，适合大型項目的一定是 React，筆者并不這麼認為，如果 Vue3 還沒出，那麼受制于 Vue2 的 Option Api，Vue 在大型項目中多少會有影響，主要展現在邏輯複用和代碼組織上，但是 Vue3 有 setup 模式下 Composition Api 的加持，Vue 也已足夠靈活，筆者認為關于“Vue 不适合大型項目”的論調可以休矣，在 Vue 和 React 特性越來越趨同的今天，如果依然出現這種想法，那可能更多還是 “人”的問題。

   這裡還有一個有意思的小插曲，筆者曾經和朋友聊天聊到 Vue 和 React，談到他對這倆架構的看法，當時他說的話令我印象很深刻，他說“React 項目要想寫好，會比同規模的 Vue 難一些，但是 React 要想寫壞，那可太容易了”，截止到目前，我對這句話仍深以為然。

6. 如果從性能上考慮，在本文的資料對比中 Vue3 要優于 React，但是之前已經說過，資料并非決定因素，尤其在帶寬足夠和裝置性能越來越強悍的今天，很多運作時的性能問題其實在裝置層面被抹平，普通業務中甚至已經不需要過多關注運作時性能了（但是保持良好的優化習慣是每個開發者的優良品質！），是以單單考慮性能，React 和 Vue，翻哪個牌子，看你心情咯。

最後，不論 React 還是 Vue，都是相當優秀的架構，在實作層面同樣都有虛拟 DOM、聲明式 UI 等特性，同時各自也都擁有着活躍的社群和周邊，并且有來自各個公司中無數業務線的成熟産品背書，在跨端上也有着非常不錯的支援。

作為前端開發者來說，其實已經掌握單一技術棧，已經遠遠不能滿足個人的發展需要了，來自就業、晉升、考核的外力總會變為那個驅使你不斷前進的内力，學習一門架構其實是要接納整個架構的生态，熵減過程總是令你不舒服，而在這一切結束之後，筆者還是希望你是有收獲、并且愉悅的，畢竟——

現在再也不是那個直接使用 JQuery 梭哈的時代了，既要、也要、還要的大潮終将卷起每個前端er...

四、參考資料（包括但不限于）

https://www.rongsoft.com/article/2022/04/161658438271/

https://www.zhihu.com/people/evanyou/answers

https://www.zhihu.com/question/47161776/answer/111370024

https://zhuanlan.zhihu.com/p/33051365

https://zhuanlan.zhihu.com/p/449058444

https://mp.weixin.qq.com/s/KCZsBmQiCdLF2HJ5N4Pbyw

https://mp.weixin.qq.com/s/IIz7WAuPTqjPRMgAybO1fg

作者：孫凱