對比其他框架（轉官方文件）

這個頁面無疑是最難編寫的，但我們認為它也是非常重要的。或許你曾遇到了一些問題並且已經用其他的框架解決了。你來這裡的目的是看看 Vue 是否有更好的解決方案。這也是我們在此想要回答的。

客觀來說，作為核心團隊成員，顯然我們會更偏愛 Vue，認為對於某些問題來講用 Vue 解決會更好。如果沒有這點信念，我們也就不會整天為此忙活了。但是在此，我們想盡可能地公平和準確地來描述一切。其他的框架也有顯著的優點，例如 React 龐大的生態系統，或者像是 Knockout 對瀏覽器的支援覆蓋到了 IE6。我們會嘗試著把這些內容全部列出來。

我們也希望得到你的幫助，來使文件保持最新狀態，因為 JavaScript 的世界進步的太快。如果你注意到一個不準確或似乎不太正確的地方，請

React

React 和 Vue 有許多相似之處，它們都有：

• 使用 Virtual DOM
• 提供了響應式 (Reactive) 和元件化 (Composable) 的檢視元件。
• 將注意力集中保持在核心庫，而將其他功能如路由和全域性狀態管理交給相關的庫。

由於有著眾多的相似處，我們會用更多的時間在這一塊進行比較。這裡我們不只保證技術內容的準確性，同時也兼顧了平衡的考量。我們需要承認 React 比 Vue 更好的地方，比如更豐富的生態系統。

React 社群為我們準確進行平衡的考量提供了非常積極的幫助，特別感謝來自 React 團隊的 Dan Abramov 。他非常慷慨的花費時間來貢獻專業知識來幫助我們完善這篇文件。

執行時效能

React 和 Vue 都是非常快的，所以速度並不是在它們之中做選擇的決定性因素。對於具體的資料表現，可以移步這個第三方 benchmark，它專注於渲染/更新非常簡單的元件樹的真實效能。

優化

在 React 應用中，當某個元件的狀態發生變化時，它會以該元件為根，重新渲染整個元件子樹。

如要避免不必要的子元件的重渲染，你需要在所有可能的地方使用 PureComponent，或是手動實現 shouldComponentUpdate 方法。同時你可能會需要使用不可變的資料結構來使得你的元件更容易被優化。

然而，使用 PureComponent 和 shouldComponentUpdate

在 Vue 應用中，元件的依賴是在渲染過程中自動追蹤的，所以系統能精確知曉哪個元件確實需要被重渲染。你可以理解為每一個元件都已經自動獲得了 shouldComponentUpdate，並且沒有上述的子樹問題限制。

Vue 的這個特點使得開發者不再需要考慮此類優化，從而能夠更好地專注於應用本身。

在 React 中，一切都是 JavaScript。不僅僅是 HTML 可以用 JSX 來表達，現在的潮流也越來越多地將 CSS 也納入到 JavaScript 中來處理。這類方案有其優點，但也存在一些不是每個開發者都能接受的取捨。

Vue 的整體思想是擁抱經典的 Web 技術，並在其上進行擴充套件。我們下面會詳細分析一下。

JSX vs Templates

在 React 中，所有的元件的渲染功能都依靠 JSX。JSX 是使用 XML 語法編寫 JavaScript 的一種語法糖。

JSX 說是手寫的渲染函式有下面這些優勢：

• 你可以使用完整的程式語言 JavaScript 功能來構建你的檢視頁面。比如你可以使用臨時變數、JS 自帶的流程控制、以及直接引用當前 JS 作用域中的值等等。

• 開發工具對 JSX 的支援相比於現有可用的其他 Vue 模板還是比較先進的 (比如，linting、型別檢查、編輯器的自動完成)。

事實上 Vue 也提供了渲染函式，甚至支援 JSX。然而，我們預設推薦的還是模板。任何合乎規範的 HTML 都是合法的 Vue 模板，這也帶來了一些特有的優勢：

• 對於很多習慣了 HTML 的開發者來說，模板比起 JSX 讀寫起來更自然。這裡當然有主觀偏好的成分，但如果這種區別會導致開發效率的提升，那麼它就有客觀的價值存在。

• 基於 HTML 的模板使得將已有的應用逐步遷移到 Vue 更為容易。

• 這也使得設計師和新人開發者更容易理解和參與到專案中。

• 你甚至可以使用其他模板前處理器，比如 Pug 來書寫 Vue 的模板。

有些開發者認為模板意味著需要學習額外的 DSL (Domain-Specific Language 領域特定語言) 才能進行開發——我們認為這種區別是比較膚淺的。首先，JSX 並不是免費的——它是基於 JS 之上的一套額外語法，因此也有它自己的學習成本。同時，正如同熟悉 JS 的人學習 JSX 會很容易一樣，熟悉 HTML 的人學習 Vue 的模板語法也是很容易的。最後，DSL 的存在使得我們可以讓開發者用更少的程式碼做更多的事，比如 v-on 的各種修飾符，在 JSX 中實現對應的功能會需要多得多的程式碼。

更抽象一點來看，我們可以把元件區分為兩類：一類是偏視圖表現的 (presentational)，一類則是偏邏輯的 (logical)。我們推薦在前者中使用模板，在後者中使用 JSX 或渲染函式。這兩類元件的比例會根據應用型別的不同有所變化，但整體來說我們發現表現類的元件遠遠多於邏輯類元件。

元件作用域內的 CSS

除非你把元件分佈在多個檔案上 (例如 CSS Modules)，CSS 作用域在 React 中是通過 CSS-in-JS 的方案實現的 (比如 styled-components、glamorous 和 emotion)。這引入了一個新的面向元件的樣式範例，它和普通的 CSS 撰寫過程是有區別的。另外，雖然在構建時將 CSS 提取到一個單獨的樣式表是支援的，但 bundle 裡通常還是需要一個執行時程式來讓這些樣式生效。當你能夠利用 JavaScript 靈活處理樣式的同時，也需要權衡 bundle 的尺寸和執行時的開銷。

如果你是一個 CSS-in-JS 的愛好者，許多主流的 CSS-in-JS 庫也都支援 Vue (比如 styled-components-vue 和 vue-emotion)。這裡 React 和 Vue 主要的區別是，Vue 設定樣式的預設方法是單檔案元件裡類似 style 的標籤。

單檔案元件讓你可以在同一個檔案裡完全控制 CSS，將其作為元件程式碼的一部分。

<style scoped>
  @media (min-width: 250px) {
    .list-container:hover {
      background: orange;
    }
  }
</style>

這個可選 scoped 屬性會自動新增一個唯一的屬性 (比如 data-v-21e5b78) 為元件內 CSS 指定作用域，編譯的時候 .list-container:hover 會被編譯成類似.list-container[data-v-21e5b78]:hover。

最後，Vue 的單檔案元件裡的樣式設定是非常靈活的。通過 vue-loader，你可以使用任意前處理器、後處理器，甚至深度整合 CSS Modules——全部都在 <style> 標籤內。

規模

向上擴充套件

Vue 和 React 都提供了強大的路由來應對大型應用。React 社群在狀態管理方面非常有創新精神 (比如 Flux、Redux)，而這些狀態管理模式甚至 Redux 本身也可以非常容易的整合在 Vue 應用中。實際上，Vue 更進一步地採用了這種模式 (Vuex)，更加深入整合 Vue 的狀態管理解決方案 Vuex 相信能為你帶來更好的開發體驗。

兩者另一個重要差異是，Vue 的路由庫和狀態管理庫都是由官方維護支援且與核心庫同步更新的。React 則是選擇把這些問題交給社群維護，因此建立了一個更分散的生態系統。但相對的，React 的生態系統相比 Vue 更加繁榮。

• 它不允許在專案生成時進行任何配置，而 Vue 支援 Yeoman-like 定製。
• 它只提供一個構建單頁面應用的單一模板，而 Vue 提供了各種用途的模板。
• 它不能用使用者自建的模板構建專案，而自建模板對企業環境下預先建立協議是特別有用的。

而要注意的是這些限制是故意設計的，這有它的優勢。例如，如果你的專案需求非常簡單，你就不需要自定義生成過程。你能把它作為一個依賴來更新。如果閱讀更多關於不同的設計理念。

向下擴充套件

React 學習曲線陡峭，在你開始學 React 前，你需要知道 JSX 和 ES2015，因為許多示例用的是這些語法。你需要學習構建系統，雖然你在技術上可以用 Babel 來實時編譯程式碼，但是這並不推薦用於生產環境。

就像 Vue 向上擴充套件好比 React 一樣，Vue 向下擴充套件後就類似於 jQuery。你只要把如下標籤放到頁面就可以執行：

<script src="https://cdn.jsdelivr.net/npm/vue"></script>

然後你就可以編寫 Vue 程式碼並應用到生產中，你只要用 min 版 Vue 檔案替換掉就不用擔心其他的效能問題。

由於起步階段不需學 JSX，ES2015 以及構建系統，所以開發者只需不到一天的時間閱讀指南就可以建立簡單的應用程式。

原生渲染

React Native 能使你用相同的元件模型編寫有本地渲染能力的 APP (iOS 和 Android)。能同時跨多平臺開發，對開發者是非常棒的。相應地，Vue 和 Weex 會進行官方合作，Weex 是阿里的跨平臺使用者介面開發框架，Weex 的 JavaScript 框架執行時用的就是 Vue。這意味著在 Weex 的幫助下，你使用 Vue 語法開發的元件不僅僅可以執行在瀏覽器端，還能被用於開發 iOS 和 Android 上的原生應用。

在現在，Weex 還在積極發展，成熟度也不能和 React Native 相抗衡。但是，Weex 的發展是由世界上最大的電子商務企業的需求在驅動，Vue 團隊也會和 Weex 團隊積極合作確保為開發者帶來良好的開發體驗。

MobX

Mobx 在 React 社群很流行，實際上在 Vue 也採用了幾乎相同的反應系統。在有限程度上，React + Mobx 也可以被認為是更繁瑣的 Vue，所以如果你習慣組合使用它們，那麼選擇 Vue 會更合理。

Vue 的一些語法和 AngularJS 的很相似 (例如 v-if vs ng-if)。因為 AngularJS 是 Vue 早期開發的靈感來源。然而，AngularJS 中存在的許多問題，在 Vue 中已經得到解決。

複雜性

在 API 與設計兩方面上 Vue.js 都比 AngularJS 簡單得多，因此你可以快速地掌握它的全部特性並投入開發。

Vue.js 是一個更加靈活開放的解決方案。它允許你以希望的方式組織應用程式，而不是在任何時候都必須遵循 AngularJS 制定的規則，這讓 Vue 能適用於各種專案。我們知道把決定權交給你是非常必要的。
這也就是為什麼我們提供 webpack template，讓你可以用幾分鐘，去選擇是否啟用高階特性，比如熱模組載入、linting、CSS 提取等等。

資料繫結

AngularJS 使用雙向繫結，Vue 在不同元件間強制使用單向資料流。這使應用中的資料流更加清晰易懂。

指令與元件

在 Vue 中指令和元件分得更清晰。指令只封裝 DOM 操作，而元件代表一個自給自足的獨立單元——有自己的檢視和資料邏輯。在 AngularJS 中兩者有不少相混的地方。

執行時效能

Vue 有更好的效能，並且非常非常容易優化，因為它不使用髒檢查。

在 AngularJS 中，當 watcher 越來越多時會變得越來越慢，因為作用域內的每一次變化，所有 watcher 都要重新計算。並且，如果一些 watcher 觸發另一個更新，髒檢查迴圈 (digest cycle) 可能要執行多次。AngularJS 使用者常常要使用深奧的技術，以解決髒檢查迴圈的問題。有時沒有簡單的辦法來優化有大量 watcher 的作用域。

Vue 則根本沒有這個問題，因為它使用基於依賴追蹤的觀察系統並且非同步佇列更新，所有的資料變化都是獨立觸發，除非它們之間有明確的依賴關係。

有意思的是，Angular 和 Vue 用相似的設計解決了一些 AngularJS 中存在的問題。

我們將新的 Angular 獨立開來討論，因為它是一個和 AngularJS 完全不同的框架。例如：它具有優秀的元件系統，並且許多實現已經完全重寫，API 也完全改變了。

Angular 事實上必須用 TypeScript 來開發，因為它的文件和學習資源幾乎全部是面向 TS 的。TS 有很多好處——靜態型別檢查在大規模的應用中非常有用，同時對於 Java 和 C# 背景的開發者也是非常提升開發效率的。

然而，並不是所有人都想用 TS——在中小型規模的專案中，引入 TS 可能並不會帶來太多明顯的優勢。在這些情況下，用 Vue 會是更好的選擇，因為在不用 TS 的情況下使用 Angular 會很有挑戰性。

最後，雖然 Vue 和 TS 的整合可能不如 Angular 那麼深入，我們也提供了官方的 型別宣告 和元件裝飾器，並且知道有大量使用者在生產環境中使用 Vue + TS 的組合。我們也和微軟的 TS / VSCode 團隊進行著積極的合作，目標是為 Vue + TS 使用者提供更好的型別檢查和 IDE 開發體驗。

執行時效能

這兩個框架都很快，有非常類似的 benchmark 資料。你可以瀏覽具體的資料做更細粒度的對比，不過速度應該不是決定性的因素。

體積

在體積方面，最近的 Angular 版本中在使用了 AOT 和 tree-shaking 技術後使得最終的程式碼體積減小了許多。但即使如此，一個包含了 Vuex + Vue Router 的 Vue 專案 (gzip 之後 30kB) 相比使用了這些優化的 angular-cli 生成的預設專案尺寸 (~130kB) 還是要小得多。

靈活性

Vue 相比於 Angular 更加靈活，Vue 官方提供了構建工具來協助你構建專案，但它並不限制你去如何組織你的應用程式碼。有人可能喜歡有嚴格的程式碼組織規範，但也有開發者喜歡更靈活自由的方式。

學習曲線

要學習 Vue，你只需要有良好的 HTML 和 JavaScript 基礎。有了這些基本的技能，你就可以非常快速地通過閱讀 指南 投入開發。

Angular 的學習曲線是非常陡峭的——作為一個框架，它的 API 面積比起 Vue 要大得多，你也因此需要理解更多的概念才能開始有效率地工作。當然，Angular 本身的複雜度是因為它的設計目標就是隻針對大型的複雜應用；但不可否認的是，這也使得它對於經驗不甚豐富的開發者相當的不友好。

Ember

Ember 是一個全能框架。它提供了大量的約定，一旦你熟悉了它們，開發會變得很高效。不過，這也意味著學習曲線較高，而且並不靈活。這意味著在框架和庫 (加上一系列鬆散耦合的工具) 之間做權衡選擇。後者會更自由，但是也要求你做更多架構上的決定。

也就是說，我們最好比較的是 Vue 核心和 Ember 的模板與資料模型層：

• Vue 在普通 JavaScript 物件上建立響應，提供自動化的計算屬性。在 Ember 中需要將所有東西放在 Ember 物件內，並且手工為計算屬性宣告依賴。

• Vue 的模板語法可以用全功能的 JavaScript 表示式，而 Handlebars 的語法和幫助函式相比來說非常受限。

• 在效能上，Vue 比 Ember 好很多，即使是 Ember 2.x 的最新 Glimmer 引擎。Vue 能夠自動批量更新，而 Ember 在效能敏感的場景時需要手動管理。

Knockout 是 MVVM 領域內的先驅，並且追蹤依賴。它的響應系統和 Vue 也很相似。它在瀏覽器支援以及其他方面的表現也是讓人印象深刻的。它最低能支援到 IE6，而 Vue 最低只能支援到 IE9。

隨著時間的推移，Knockout 的發展已有所放緩，並且略顯有點老舊了。比如，它的元件系統缺少完備的生命週期事件方法，儘管這些在現在是非常常見的。以及相比於 Vue 呼叫子元件的介面它的方法顯得有點笨重。

如果你有興趣研究，你還會發現二者在介面設計的理念上是不同的。這可以通過各自建立的simple Todo List 體現出來。或許有點主觀，但是很多人認為 Vue 的 API 介面更簡單結構更優雅。

Polymer 是另一個由谷歌贊助的專案，事實上也是 Vue 的一個靈感來源。Vue 的元件可以粗略的類比於 Polymer 的自定義元素，並且兩者具有相似的開發風格。最大的不同之處在於，Polymer 是基於最新版的 Web Components 標準之上，並且需要重量級的 polyfills 來幫助工作 (效能下降)，瀏覽器本身並不支援這些功能。相比而言，Vue 在支援到 IE9 的情況下並不需要依賴 polyfills 來工作。

在 Polymer 1.0 版本中，為了彌補效能，團隊非常有限的使用資料繫結系統。例如，在 Polymer 中唯一支援的表示式只有布林值否定和單一的方法呼叫，它的 computed 方法的實現也並不是很靈活。

Polymer 自定義的元素是用 HTML 檔案來建立的，這會限制使用 JavaScript/CSS (和被現代瀏覽器普遍支援的語言特性)。相比之下，Vue 的單檔案元件允許你非常容易的使用 ES2015 和你想用的 CSS 預編譯處理器。

在部署生產環境時，Polymer 建議使用 HTML Imports 載入所有資源。而這要求伺服器和客戶端都支援 Http 2.0 協議，並且瀏覽器實現了此標準。這是否可行就取決於你的目標使用者和部署環境了。如果狀況不佳，你必須用 Vulcanizer 工具來打包 Polymer 元素。而在這方面，Vue 可以結合非同步元件的特性和 Webpack 的程式碼分割特性來實現懶載入 (lazy-loaded)。這同時確保了對舊瀏覽器的相容且又能更快載入。

而 Vue 和 Web Component 標準進行深層次的整合也是完全可行的，比如使用 Custom Elements、Shadow DOM 的樣式封裝。然而在我們做出嚴肅的實現承諾之前，我們目前仍在等待相關標準成熟，進而再廣泛應用於主流的瀏覽器中。

Riot

Riot 3.0 提供了一個類似於基於元件的開發模型 (在 Riot 中稱之為 Tag)，它提供了小巧精美的 API。Riot 和 Vue 在設計理念上可能有許多相似處。儘管相比 Riot ，Vue 要顯得重一點，Vue 還是有很多顯著優勢的：

• 更好的效能。Riot 使用了 遍歷 DOM 樹 而不是虛擬 DOM，但實際上用的還是髒檢查機制，因此和 AngularJS 患有相同的效能問題。
• 更多成熟工具的支援。Vue 提供官方支援 webpack 和 Browserify，而 Riot 是依靠社群來建立整合系統。