對(duì)比其他框架
將Vue和React、AngularJS (Angular 1)、Angular (原本的 Angular 2)、Ember、Knockout、Polymer、Riot等框架對(duì)比一下
這個(gè)頁(yè)面無(wú)疑是最難編寫(xiě)的，但我們認(rèn)為它也是非常重要的?；蛟S你曾遇到了一些問(wèn)題并且已經(jīng)用其他的框架解決了。你來(lái)這里的目的是看看 Vue 是否有更好的解決方案。這也是我們?cè)诖讼胍卮鸬摹?br/>
客觀來(lái)說(shuō)，作為核心團(tuán)隊(duì)成員，顯然我們會(huì)更偏愛(ài) Vue，認(rèn)為對(duì)于某些問(wèn)題來(lái)講用 Vue 解決會(huì)更好。如果沒(méi)有這點(diǎn)信念，我們也就不會(huì)整天為此忙活了。但是在此，我們想盡可能地公平和準(zhǔn)確地來(lái)描述一切。其他的框架也有顯著的優(yōu)點(diǎn)，例如 React 龐大的生態(tài)系統(tǒng)，或者像是 Knockout 對(duì)瀏覽器的支持覆蓋到了 IE6。我們會(huì)嘗試著把這些內(nèi)容全部列出來(lái)。
我們也希望得到你的幫助，來(lái)使文檔保持最新?tīng)顟B(tài)，因?yàn)?JavaScript 的世界進(jìn)步的太快。如果你注意到一個(gè)不準(zhǔn)確或似乎不太正確的地方，請(qǐng)提交問(wèn)題讓我們知道。
目錄
React
React 和 Vue 有許多相似之處，它們都有：
使用 Virtual DOM
提供了響應(yīng)式 (Reactive) 和組件化 (Composable) 的視圖組件。
將注意力集中保持在核心庫(kù)，而將其他功能如路由和全局狀態(tài)管理交給相關(guān)的庫(kù)。
由于有著眾多的相似處，我們會(huì)用更多的時(shí)間在這一塊進(jìn)行比較。這里我們不只保證技術(shù)內(nèi)容的準(zhǔn)確性，同時(shí)也兼顧了平衡的考量。我們需要承認(rèn) React 比 Vue 更好的地方，比如更豐富的生態(tài)系統(tǒng)。
下列部分章節(jié)會(huì)略微有些過(guò)時(shí)，因?yàn)樽罱?React 16+ 的發(fā)布，我們計(jì)劃在不久的將來(lái)和 React 社區(qū)一起重寫(xiě)這部分內(nèi)容。
運(yùn)行時(shí)性能
React 和 Vue 都是非?？斓?，所以速度并不是在它們之中做選擇的決定性因素。對(duì)于具體的數(shù)據(jù)表現(xiàn)，可以移步這個(gè)第三方 benchmark，它專注于渲染/更新非常簡(jiǎn)單的組件樹(shù)的真實(shí)性能。
優(yōu)化
在 React 應(yīng)用中，當(dāng)某個(gè)組件的狀態(tài)發(fā)生變化時(shí)，它會(huì)以該組件為根，重新渲染整個(gè)組件子樹(shù)。
如要避免不必要的子組件的重渲染，你需要在所有可能的地方使用 PureComponent，或是手動(dòng)實(shí)現(xiàn) shouldComponentUpdate 方法。同時(shí)你可能會(huì)需要使用不可變的數(shù)據(jù)結(jié)構(gòu)來(lái)使得你的組件更容易被優(yōu)化。
然而，使用 PureComponent 和 shouldComponentUpdate 時(shí)，需要保證該組件的整個(gè)子樹(shù)的渲染輸出都是由該組件的 props 所決定的。如果不符合這個(gè)情況，那么此類優(yōu)化就會(huì)導(dǎo)致難以察覺(jué)的渲染結(jié)果不一致。這使得 React 中的組件優(yōu)化伴隨著相當(dāng)?shù)男闹秦?fù)擔(dān)。
在 Vue 應(yīng)用中，組件的依賴是在渲染過(guò)程中自動(dòng)追蹤的，所以系統(tǒng)能精確知曉哪個(gè)組件確實(shí)需要被重渲染。你可以理解為每一個(gè)組件都已經(jīng)自動(dòng)獲得了 shouldComponentUpdate，并且沒(méi)有上述的子樹(shù)問(wèn)題限制。
Vue 的這個(gè)特點(diǎn)使得開(kāi)發(fā)者不再需要考慮此類優(yōu)化，從而能夠更好地專注于應(yīng)用本身。
HTML & CSS
在 React 中，一切都是 JavaScript。不僅僅是 HTML 可以用 JSX 來(lái)表達(dá)，現(xiàn)在的潮流也越來(lái)越多地將 CSS 也納入到 JavaScript 中來(lái)處理。這類方案有其優(yōu)點(diǎn)，但也存在一些不是每個(gè)開(kāi)發(fā)者都能接受的取舍。
Vue 的整體思想是擁抱經(jīng)典的 Web 技術(shù)，并在其上進(jìn)行擴(kuò)展。我們下面會(huì)詳細(xì)分析一下。
JSX vs Templates
在 React 中，所有的組件的渲染功能都依靠 JSX。JSX 是使用 XML 語(yǔ)法編寫(xiě) JavaScript 的一種語(yǔ)法糖。
使用 JSX 的渲染函數(shù)有下面這些優(yōu)勢(shì)：
你可以使用完整的編程語(yǔ)言 JavaScript 功能來(lái)構(gòu)建你的視圖頁(yè)面。比如你可以使用臨時(shí)變量、JS 自帶的流程控制、以及直接引用當(dāng)前 JS 作用域中的值等等。
開(kāi)發(fā)工具對(duì) JSX 的支持相比于現(xiàn)有可用的其他 Vue 模板還是比較先進(jìn)的 (比如，linting、類型檢查、編輯器的自動(dòng)完成)。
事實(shí)上 Vue 也提供了 渲染函數(shù)，甚至支持 JSX。然而，我們默認(rèn)推薦的還是模板。任何合乎規(guī)范的 HTML 都是合法的 Vue 模板，這也帶來(lái)了一些特有的優(yōu)勢(shì)：
對(duì)于很多習(xí)慣了 HTML 的開(kāi)發(fā)者來(lái)說(shuō)，模板比起 JSX 讀寫(xiě)起來(lái)更自然。這里當(dāng)然有主觀偏好的成分，但如果這種區(qū)別會(huì)導(dǎo)致開(kāi)發(fā)效率的提升，那么它就有客觀的價(jià)值存在。
基于 HTML 的模板使得將已有的應(yīng)用逐步遷移到 Vue 更為容易。
這也使得設(shè)計(jì)師和新人開(kāi)發(fā)者更容易理解和參與到項(xiàng)目中。
你甚至可以使用其他模板預(yù)處理器，比如 Pug 來(lái)書(shū)寫(xiě) Vue 的模板。
有些開(kāi)發(fā)者認(rèn)為模板意味著需要學(xué)習(xí)額外的 DSL (Domain-Specific Language 領(lǐng)域特定語(yǔ)言) 才能進(jìn)行開(kāi)發(fā)——我們認(rèn)為這種區(qū)別是比較膚淺的。首先，JSX 并不是沒(méi)有學(xué)習(xí)成本的——它是基于 JS 之上的一套額外語(yǔ)法。同時(shí)，正如同熟悉 JS 的人學(xué)習(xí) JSX 會(huì)很容易一樣，熟悉 HTML 的人學(xué)習(xí) Vue 的模板語(yǔ)法也是很容易的。最后，DSL 的存在使得我們可以讓開(kāi)發(fā)者用更少的代碼做更多的事，比如 v-on 的各種修飾符，在 JSX 中實(shí)現(xiàn)對(duì)應(yīng)的功能會(huì)需要多得多的代碼。
更抽象一點(diǎn)來(lái)看，我們可以把組件區(qū)分為兩類：一類是偏視圖表現(xiàn)的 (presentational)，一類則是偏邏輯的 (logical)。我們推薦在前者中使用模板，在后者中使用 JSX 或渲染函數(shù)。這兩類組件的比例會(huì)根據(jù)應(yīng)用類型的不同有所變化，但整體來(lái)說(shuō)我們發(fā)現(xiàn)表現(xiàn)類的組件遠(yuǎn)遠(yuǎn)多于邏輯類組件。
組件作用域內(nèi)的 CSS
除非你把組件分布在多個(gè)文件上 (例如 CSS Modules)，CSS 作用域在 React 中是通過(guò) CSS-in-JS 的方案實(shí)現(xiàn)的 (比如 styled-components、glamorous 和 emotion)。這引入了一個(gè)新的面向組件的樣式范例，它和普通的 CSS 撰寫(xiě)過(guò)程是有區(qū)別的。另外，雖然在構(gòu)建時(shí)將 CSS 提取到一個(gè)單獨(dú)的樣式表是支持的，但 bundle 里通常還是需要一個(gè)運(yùn)行時(shí)程序來(lái)讓這些樣式生效。當(dāng)你能夠利用 JavaScript 靈活處理樣式的同時(shí)，也需要權(quán)衡 bundle 的尺寸和運(yùn)行時(shí)的開(kāi)銷。
如果你是一個(gè) CSS-in-JS 的愛(ài)好者，許多主流的 CSS-in-JS 庫(kù)也都支持 Vue (比如 styled-components-vue 和 vue-emotion)。這里 React 和 Vue 主要的區(qū)別是，Vue 設(shè)置樣式的默認(rèn)方法是單文件組件里類似 style 的標(biāo)簽。
單文件組件讓你可以在同一個(gè)文件里完全控制 CSS，將其作為組件代碼的一部分。
<style scoped>
@media (min-width: 250px) {
.list-container:hover {
background: orange;
}
}
</style>這個(gè)可選 scoped 屬性會(huì)自動(dòng)添加一個(gè)唯一的屬性 (比如 data-v-21e5b78) 為組件內(nèi) CSS 指定作用域，編譯的時(shí)候 .list-container:hover 會(huì)被編譯成類似 .list-container[data-v-21e5b78]:hover。
最后，Vue 的單文件組件里的樣式設(shè)置是非常靈活的。通過(guò) vue-loader，你可以使用任意預(yù)處理器、后處理器，甚至深度集成 CSS Modules——全部都在 <style> 標(biāo)簽內(nèi)。
規(guī)模
向上擴(kuò)展
Vue 和 React 都提供了強(qiáng)大的路由來(lái)應(yīng)對(duì)大型應(yīng)用。React 社區(qū)在狀態(tài)管理方面非常有創(chuàng)新精神 (比如 Flux、Redux)，而這些狀態(tài)管理模式甚至 Redux 本身 也可以非常容易的集成在 Vue 應(yīng)用中。實(shí)際上，Vue 更進(jìn)一步地采用了這種模式 (Vuex)，更加深入集成 Vue 的狀態(tài)管理解決方案 Vuex 相信能為你帶來(lái)更好的開(kāi)發(fā)體驗(yàn)。
兩者另一個(gè)重要差異是，Vue 的路由庫(kù)和狀態(tài)管理庫(kù)都是由官方維護(hù)支持且與核心庫(kù)同步更新的。React 則是選擇把這些問(wèn)題交給社區(qū)維護(hù)，因此創(chuàng)建了一個(gè)更分散的生態(tài)系統(tǒng)。但相對(duì)的，React 的生態(tài)系統(tǒng)相比 Vue 更加繁榮。
最后，Vue 提供了 CLI 腳手架，能讓你通過(guò)交互式的腳手架引導(dǎo)非常容易地構(gòu)建項(xiàng)目。你甚至可以使用它快速開(kāi)發(fā)組件的原型。React 在這方面也提供了 create-react-app，但是現(xiàn)在還存在一些局限性：
它不允許在項(xiàng)目生成時(shí)進(jìn)行任何配置，而 Vue CLI 運(yùn)行于可升級(jí)的運(yùn)行時(shí)依賴之上，該運(yùn)行時(shí)可以通過(guò)插件進(jìn)行擴(kuò)展。
它只提供一個(gè)構(gòu)建單頁(yè)面應(yīng)用的默認(rèn)選項(xiàng)，而 Vue 提供了各種用途的模板。
它不能用用戶自建的 預(yù)設(shè)配置 構(gòu)建項(xiàng)目，這對(duì)企業(yè)環(huán)境下預(yù)先建立約定是特別有用的。
而要注意的是這些限制是故意設(shè)計(jì)的，這有它的優(yōu)勢(shì)。例如，如果你的項(xiàng)目需求非常簡(jiǎn)單，你就不需要自定義生成過(guò)程。你能把它作為一個(gè)依賴來(lái)更新。如果閱讀更多關(guān)于不同的設(shè)計(jì)理念。
向下擴(kuò)展
React 學(xué)習(xí)曲線陡峭，在你開(kāi)始學(xué) React 前，你需要知道 JSX 和 ES2015，因?yàn)樵S多示例用的是這些語(yǔ)法。你需要學(xué)習(xí)構(gòu)建系統(tǒng)，雖然你在技術(shù)上可以用 Babel 來(lái)實(shí)時(shí)編譯代碼，但是這并不推薦用于生產(chǎn)環(huán)境。
就像 Vue 向上擴(kuò)展好比 React 一樣，Vue 向下擴(kuò)展后就類似于 jQuery。你只要把如下標(biāo)簽放到頁(yè)面就可以運(yùn)行：
<script src="https://cdn.jsdelivr.net/npm/vue"></script>
然后你就可以編寫(xiě) Vue 代碼并應(yīng)用到生產(chǎn)中，你只要用 min 版 Vue 文件替換掉就不用擔(dān)心其他的性能問(wèn)題。
由于起步階段不需學(xué) JSX，ES2015 以及構(gòu)建系統(tǒng)，所以開(kāi)發(fā)者只需不到一天的時(shí)間閱讀指南就可以建立簡(jiǎn)單的應(yīng)用程序。
原生渲染
React Native 能使你用相同的組件模型編寫(xiě)有本地渲染能力的 APP (iOS 和 Android)。能同時(shí)跨多平臺(tái)開(kāi)發(fā)，對(duì)開(kāi)發(fā)者是非常棒的。相應(yīng)地，Vue 和 Weex 會(huì)進(jìn)行官方合作，Weex 是阿里巴巴發(fā)起的跨平臺(tái)用戶界面開(kāi)發(fā)框架，同時(shí)也正在 Apache 基金會(huì)進(jìn)行項(xiàng)目孵化，Weex 允許你使用 Vue 語(yǔ)法開(kāi)發(fā)不僅僅可以運(yùn)行在瀏覽器端，還能被用于開(kāi)發(fā) iOS 和 Android 上的原生應(yīng)用的組件。
在現(xiàn)在，Weex 還在積極發(fā)展，成熟度也不能和 React Native 相抗衡。但是，Weex 的發(fā)展是由世界上最大的電子商務(wù)企業(yè)的需求在驅(qū)動(dòng)，Vue 團(tuán)隊(duì)也會(huì)和 Weex 團(tuán)隊(duì)積極合作確保為開(kāi)發(fā)者帶來(lái)良好的開(kāi)發(fā)體驗(yàn)。
另一個(gè)選擇是 NativeScript-Vue，一個(gè)用 Vue.js 構(gòu)建完全原生應(yīng)用的 NativeScript 插件。
MobX
Mobx 在 React 社區(qū)很流行，實(shí)際上在 Vue 也采用了幾乎相同的反應(yīng)系統(tǒng)。在有限程度上，React + Mobx 也可以被認(rèn)為是更繁瑣的 Vue，所以如果你習(xí)慣組合使用它們，那么選擇 Vue 會(huì)更合理。
Preact 和其它類 React 庫(kù)
類 React 的庫(kù)們往往盡可能地與 React 共享 API 和生態(tài)。因此上述比較對(duì)它們來(lái)說(shuō)也同樣適用。它們和 React 的不同往往在于更小的生態(tài)。因?yàn)檫@些庫(kù)無(wú)法 100% 兼容 React 生態(tài)中的全部，部分工具和輔助庫(kù)也可能無(wú)法使用?；蛘呒词箍瓷先ツ芄ぷ?，但也有可能隨時(shí)發(fā)生不兼容，除非你用的這個(gè)類 React 庫(kù)官方與 React 保持嚴(yán)格一致。
AngularJS (Angular 1)
Vue 的一些語(yǔ)法和 AngularJS 的很相似 (例如 v-if vs ng-if)。因?yàn)?AngularJS 是 Vue 早期開(kāi)發(fā)的靈感來(lái)源。然而，AngularJS 中存在的許多問(wèn)題，在 Vue 中已經(jīng)得到解決。
復(fù)雜性
在 API 與設(shè)計(jì)兩方面上 Vue.js 都比 AngularJS 簡(jiǎn)單得多，因此你可以快速地掌握它的全部特性并投入開(kāi)發(fā)。
靈活性和模塊化
Vue.js 是一個(gè)更加靈活開(kāi)放的解決方案。它允許你以希望的方式組織應(yīng)用程序，而不是在任何時(shí)候都必須遵循 AngularJS 制定的規(guī)則，這讓 Vue 能適用于各種項(xiàng)目。我們知道把決定權(quán)交給你是非常必要的。
這也是為什么我們提供了一個(gè)基于 Vue.js 進(jìn)行快速開(kāi)發(fā)的完整系統(tǒng)。Vue CLI 旨在成為 Vue 生態(tài)系統(tǒng)中標(biāo)準(zhǔn)的基礎(chǔ)工具。它使得多樣化的構(gòu)建工具通過(guò)妥善的默認(rèn)配置無(wú)縫協(xié)作在一起。這樣你就可以專注在應(yīng)用本身，而不會(huì)在配置上花費(fèi)太多時(shí)間。同時(shí)，它也提供了根據(jù)實(shí)際需求調(diào)整每個(gè)工具配置的靈活性。
數(shù)據(jù)綁定
AngularJS 使用雙向綁定，Vue 在不同組件間強(qiáng)制使用單向數(shù)據(jù)流。這使應(yīng)用中的數(shù)據(jù)流更加清晰易懂。
指令與組件
在 Vue 中指令和組件分得更清晰。指令只封裝 DOM 操作，而組件代表一個(gè)自給自足的獨(dú)立單元——有自己的視圖和數(shù)據(jù)邏輯。在 AngularJS 中，每件事都由指令來(lái)做，而組件只是一種特殊的指令。
運(yùn)行時(shí)性能
Vue 有更好的性能，并且非常非常容易優(yōu)化，因?yàn)樗皇褂门K檢查。
在 AngularJS 中，當(dāng) watcher 越來(lái)越多時(shí)會(huì)變得越來(lái)越慢，因?yàn)樽饔糜騼?nèi)的每一次變化，所有 watcher 都要重新計(jì)算。并且，如果一些 watcher 觸發(fā)另一個(gè)更新，臟檢查循環(huán) (digest cycle) 可能要運(yùn)行多次。AngularJS 用戶常常要使用深?yuàn)W的技術(shù)，以解決臟檢查循環(huán)的問(wèn)題。有時(shí)沒(méi)有簡(jiǎn)單的辦法來(lái)優(yōu)化有大量 watcher 的作用域。
Vue 則根本沒(méi)有這個(gè)問(wèn)題，因?yàn)樗褂没谝蕾囎粉櫟挠^察系統(tǒng)并且異步隊(duì)列更新，所有的數(shù)據(jù)變化都是獨(dú)立觸發(fā)，除非它們之間有明確的依賴關(guān)系。
有意思的是，Angular 和 Vue 用相似的設(shè)計(jì)解決了一些 AngularJS 中存在的問(wèn)題。
Angular (原本的 Angular 2)
我們將新的 Angular 獨(dú)立開(kāi)來(lái)討論，因?yàn)樗且粋€(gè)和 AngularJS 完全不同的框架。例如：它具有優(yōu)秀的組件系統(tǒng)，并且許多實(shí)現(xiàn)已經(jīng)完全重寫(xiě)，API 也完全改變了。
TypeScript
Angular 事實(shí)上必須用 TypeScript 來(lái)開(kāi)發(fā)，因?yàn)樗奈臋n和學(xué)習(xí)資源幾乎全部是面向 TS 的。TS 有很多好處——靜態(tài)類型檢查在大規(guī)模的應(yīng)用中非常有用，同時(shí)對(duì)于 Java 和 C# 背景的開(kāi)發(fā)者也是非常提升開(kāi)發(fā)效率的。
然而，并不是所有人都想用 TS——在中小型規(guī)模的項(xiàng)目中，引入 TS 可能并不會(huì)帶來(lái)太多明顯的優(yōu)勢(shì)。在這些情況下，用 Vue 會(huì)是更好的選擇，因?yàn)樵诓挥?TS 的情況下使用 Angular 會(huì)很有挑戰(zhàn)性。
最后，雖然 Vue 和 TS 的整合可能不如 Angular 那么深入，我們也提供了官方的 類型聲明 和 組件裝飾器，并且知道有大量用戶在生產(chǎn)環(huán)境中使用 Vue + TS 的組合。我們也和微軟的 TS / VSCode 團(tuán)隊(duì)進(jìn)行著積極的合作，目標(biāo)是為 Vue + TS 用戶提供更好的類型檢查和 IDE 開(kāi)發(fā)體驗(yàn)。
運(yùn)行時(shí)性能
這兩個(gè)框架都很快，有非常類似的 benchmark 數(shù)據(jù)。你可以瀏覽具體的數(shù)據(jù)做更細(xì)粒度的對(duì)比，不過(guò)速度應(yīng)該不是決定性的因素。
體積
在體積方面，最近的 Angular 版本中在使用了 AOT 和 tree-shaking 技術(shù)后使得最終的代碼體積減小了許多。但即使如此，一個(gè)包含了 Vuex + Vue Router 的 Vue 項(xiàng)目 (gzip 之后 30kB) 相比使用了這些優(yōu)化的 angular-cli 生成的默認(rèn)項(xiàng)目尺寸 (~65KB) 還是要小得多。
靈活性
Vue 相比于 Angular 更加靈活，Vue 官方提供了構(gòu)建工具來(lái)協(xié)助你構(gòu)建項(xiàng)目，但它并不限制你去如何組織你的應(yīng)用代碼。有人可能喜歡有嚴(yán)格的代碼組織規(guī)范，但也有開(kāi)發(fā)者喜歡更靈活自由的方式。
學(xué)習(xí)曲線
要學(xué)習(xí) Vue，你只需要有良好的 HTML 和 JavaScript 基礎(chǔ)。有了這些基本的技能，你就可以非常快速地通過(guò)閱讀 指南 投入開(kāi)發(fā)。
Angular 的學(xué)習(xí)曲線是非常陡峭的——作為一個(gè)框架，它的 API 面積比起 Vue 要大得多，你也因此需要理解更多的概念才能開(kāi)始有效率地工作。當(dāng)然，Angular 本身的復(fù)雜度是因?yàn)樗脑O(shè)計(jì)目標(biāo)就是只針對(duì)大型的復(fù)雜應(yīng)用；但不可否認(rèn)的是，這也使得它對(duì)于經(jīng)驗(yàn)不甚豐富的開(kāi)發(fā)者相當(dāng)?shù)牟挥押谩?/p>
Ember
Ember 是一個(gè)全能框架。它提供了大量的約定，一旦你熟悉了它們，開(kāi)發(fā)會(huì)變得很高效。不過(guò)，這也意味著學(xué)習(xí)曲線較高，而且并不靈活。這意味著在框架和庫(kù) (加上一系列松散耦合的工具) 之間做權(quán)衡選擇。后者會(huì)更自由，但是也要求你做更多架構(gòu)上的決定。
也就是說(shuō)，我們最好比較的是 Vue 內(nèi)核和 Ember 的模板與數(shù)據(jù)模型層：
Vue 在普通 JavaScript 對(duì)象上建立響應(yīng)，提供自動(dòng)化的計(jì)算屬性。在 Ember 中需要將所有東西放在 Ember 對(duì)象內(nèi)，并且手工為計(jì)算屬性聲明依賴。
Vue 的模板語(yǔ)法可以用全功能的 JavaScript 表達(dá)式，而 Handlebars 的語(yǔ)法和幫助函數(shù)相比來(lái)說(shuō)非常受限。
在性能上，Vue 比 Ember 好很多，即使是 Ember 3.x 的最新 Glimmer 引擎。Vue 能夠自動(dòng)批量更新，而 Ember 在性能敏感的場(chǎng)景時(shí)需要手動(dòng)管理。
Knockout
Knockout 是 MVVM 領(lǐng)域內(nèi)的先驅(qū)，并且追蹤依賴。它的響應(yīng)系統(tǒng)和 Vue 也很相似。它在瀏覽器支持以及其他方面的表現(xiàn)也是讓人印象深刻的。它最低能支持到 IE6，而 Vue 最低只能支持到 IE9。
隨著時(shí)間的推移，Knockout 的發(fā)展已有所放緩，并且略顯有點(diǎn)老舊了。比如，它的組件系統(tǒng)缺少完備的生命周期事件方法，盡管這些在現(xiàn)在是非常常見(jiàn)的。以及相比于 Vue 調(diào)用子組件的接口它的方法顯得有點(diǎn)笨重。
如果你有興趣研究，你還會(huì)發(fā)現(xiàn)二者在接口設(shè)計(jì)的理念上是不同的。這可以通過(guò)各自創(chuàng)建的 simple Todo List 體現(xiàn)出來(lái)。或許有點(diǎn)主觀，但是很多人認(rèn)為 Vue 的 API 接口更簡(jiǎn)單結(jié)構(gòu)更優(yōu)雅。
Polymer
Polymer 是另一個(gè)由谷歌贊助的項(xiàng)目，事實(shí)上也是 Vue 的一個(gè)靈感來(lái)源。Vue 的組件可以粗略的類比于 Polymer 的自定義元素，并且兩者具有相似的開(kāi)發(fā)風(fēng)格。最大的不同之處在于，Polymer 是基于最新版的 Web Components 標(biāo)準(zhǔn)之上，并且需要重量級(jí)的 polyfills 來(lái)幫助工作 (性能下降)，瀏覽器本身并不支持這些功能。相比而言，Vue 在支持到 IE9 的情況下并不需要依賴 polyfills 來(lái)工作。
在 Polymer 版本中，為了彌補(bǔ)性能，團(tuán)隊(duì)非常有限的使用數(shù)據(jù)綁定系統(tǒng)。例如，在 Polymer 中唯一支持的表達(dá)式只有布爾值否定和單一的方法調(diào)用，它的 computed 方法的實(shí)現(xiàn)也并不是很靈活。
Riot
Riot 3.0 提供了一個(gè)類似于基于組件的開(kāi)發(fā)模型 (在 Riot 中稱之為 Tag)，它提供了小巧精美的 API。Riot 和 Vue 在設(shè)計(jì)理念上可能有許多相似處。盡管相比 Riot ，Vue 要顯得重一點(diǎn)，Vue 還是有很多顯著優(yōu)勢(shì)的：
更好的性能。Riot 使用了 遍歷 DOM 樹(shù) 而不是虛擬 DOM，但實(shí)際上用的還是臟檢查機(jī)制，因此和 AngularJS 患有相同的性能問(wèn)題。
更多成熟工具的支持。Vue 提供官方支持 webpack 和 Browserify，而 Riot 是依靠社區(qū)來(lái)建立集成系統(tǒng)。