這個頁面無疑是最難編寫的,但也是很是重要的。或許你遇到了一些問題而且先前用其餘的框架解決了。來這裏的目的是看看Vue是否有更好的解決方案。那麼你就來對了。css
客觀來講,做爲核心團隊成員,顯然咱們會更偏心Vue,對於某些問題用Vue來解決會更好,若是沒有這點信念,咱們也就不會成天爲此忙活了。可是,咱們想盡量地公平和準確地來說述。其餘的框架也有顯著的優勢,好比 Rect 的生態系統,或者 Knockout 對瀏覽器支持到 IE6 。咱們把這些也都會全列出來。html
咱們但願獲得大家的幫助,來使文檔保持更新,由於 JavaScript 的世界進步的太快。若是你注意到一個不許確或彷佛不太正確的地方,請提交問題讓咱們知道。vue
React 和 Vue 有許多類似之處,它們都有:react
類似的做用域,咱們會用更多的時間來說這一塊的比較。不只咱們要保持技術的準確性,同時兼顧平衡。咱們指出React比Vue更好的地方,例如,他們的生態系統和豐富的自定義渲染器。webpack
React社區在這裏很是積極地幫助咱們實現這一平衡,特別感謝來自 React 團隊的 Dan Abramov 。他很是慷慨的花費時間來貢獻專業知識,來幫咱們完善這個文件,直到咱們都滿意。git
這麼說,就是但願你能對這兩個庫的比較的公平性感到放心。github
到目前爲止,在現實的測試中,Vue 是優於 React 的(一般至少快20%-50%,儘管在某些狀況下還要更快)。咱們能夠提供一個到這個參照項目的連接,可是坦率的說,全部的參照在某些方面是有缺陷的,不多有像你所寫的一個真實應用。那麼,讓咱們詳細瞭解下吧。web
在渲染用戶界面的時候,DOM的操做是最昂貴,不幸的是沒有庫可讓這些原始操做變得更快。
咱們能作的最好的就是:vuex
假如說,在React中,渲染一個元素的額外開銷是1,而平均渲染一個組件的開銷是2。在Vue中,一個元素的開銷更像0.1,可是平均組件的開銷將是4,這是因爲一些系統的設置。vue-cli
這意味着什麼呢,在大多數的應用中,須要渲染的元素比組件的數量是更多的,因此Vue的性能表現將會遠優於React。然而,在極端狀況下,好比每一個組件渲染一個元素,Vue 將一般會較慢。
Vue 和 React 也提供提供功能性組件,這些組件都是沒有聲明,沒有實例化,所以須要更少的開銷。當這些都用於性能的關鍵位置,Vue會更快。爲了證實這點,咱們創建一個簡單的參照項目,它只是渲染 10,000 個列表項 100次。咱們鼓勵你本身去試一下,實際上,因爲瀏覽器和硬件的緣由,結果會有所不一樣,因爲 JavaScript 引擎的不一樣,結果也會有很大不一樣。
若是你懶得去作,下面的數字數字從一個運行在 Chrome 52 在一個 2014年產的 MacBook Air上。爲了不偶然性,每一個參照項目都分開運行20次,和包含的最好的結果:
Vue | React | |
---|---|---|
Fastest | 23ms | 63ms |
Median | 42ms | 81ms |
Average | 51ms | 94ms |
95th Perc. | 73ms | 164ms |
Slowest | 343ms | 453ms |
在React中,你須要在每一個地方去實現 shouldComponentUpdate
,而且用immutable數據結構才能實現徹底徹底優化的 re-renders 。在 Vue 中,組件的依賴被自動追蹤,因此當這些依賴項變更時,它纔會更新。在長列表中,有時候須要進一步優化的話,只須要在每項上添加 key
屬性。
這意味着,因爲Vue內改進過的渲染性能,更新未經優化的Vue會比未經優化的React要快的多。甚至全面優化過的React一般也會慢於未加處理的Vue。
顯然,在生產中的性能是最重要的,而且也是到目前爲止咱們所討論的。開發過程當中的表現也是很重要的。好消息是用 Vue 和 React 開發大多數應用的速度都是足夠快的。
然而,當你要開發一個對性能要求比較高的數據可視化或者動畫的應用時,這將會頗有用。在開發中, Vue 每秒最高處理10幀,而 React 每秒最高處理不到1幀。
這是因爲 React 有大量的檢查機制,這能讓它提供許多有用的警告和錯誤提示信息。咱們贊成那些很重要的,但在咱們實現這些檢查時候,也更加密切地關注着性能。
在React中,全部的都是 JavaScript,聽起來十分簡單和優雅。不幸的事實是,JavaScript 內的 HTML 和 CSS 會引發不少痛苦。在 Vue 中咱們採用的 Web 技術並在其上面擴展。接下來將經過一些實例向你展現這所意味的是什麼。
在 React 中,全部的組件的渲染功能使用的都是JSX。JSX 是使用 XML 語法編寫 Javascript 的一種語法糖。這有一個經過React社區審覈過的例子:
render () { let { items } = this.props let children if ( items.length > 0 ) { children = ( <ul> {items.map( item => <li key={item.id}>{item.name}</li> )} </ul> ) } else { children = <p>No items found.</p> } return ( <div className = 'list-container'> {children} </div> ) }
JSX的渲染功能有一些優點:
在 Vue 中,因爲有時須要用那些功能,咱們也提供了渲染功能 而且 支持JSX 。然而,對於大多數組件來講,渲染功能是不推薦使用了。
在這方面,咱們提供的是個更簡單的模板:
<template> <div class="list-container"> <ul v-if="items.length"> <li v-for="item in items"> {{ item.name }} </li> </ul> <p v-else>No items found.</p> </div> </template>
優點以下:
這樣,不只開發人員更容易編寫代碼,設計人員和開發人員也能夠更容易的分析代碼和貢獻代碼。
尚未結束。Vue擁抱HTML,而不是用JavaScript重塑它。在模板內,Vue也容許你用預處理器好比Pub(原名 Jade) 。
React 生態也有一個項目容許你寫模板,可是有一些缺點:
除非你把組件分佈在多個文件上(例如 CSS Modules),要不做用域內的CSS就會暴警告。很是簡單的CSS還能夠工做,可是稍微複雜點的,好比懸停狀態、媒體查詢、僞類選擇符要麼會被修改要麼就不能用。
Vue讓你能夠徹底訪問 單文件組件 。
<style scoped> @media (min-width: 250px) { .list-container:hover { background: orange; } } </style>
這個可選 scoped
屬性自動添加一個惟一的屬性(好比 data-v-1
)爲組件內CSS指定做用範圍,編譯的時候 .list-container:hover
會被編譯成相似.list-container[data-v-1]:hover
。
最後,你能夠選擇本身偏心的CSS預處理器編寫CSS。這可讓你圍繞設計爲中心展開工做,而不是引入庫來增長你應用的容量和複雜度。
Vue和React都提供了強大的路由來應對對於大型應用。React社區在狀態管理方面很是有創新精神(好比Flux、Redux),而這些狀態管理模式甚至 Redux自己 也是很是容易可以集成在Vue應用中的。實際上,Vue更進一步地採用了這種模式(Vuex),把Vuex集成進Vue能帶來更好的開發體驗。
二者另外一個重要差別是,Vue伴隨的路由庫和狀態管理庫都是由官方支持維護且和核心庫同步更新的。React 生態更成熟,選擇是把這些問題交給社區維護。
最後,Vue 提供了一個Vue-cli 腳手架,能讓你很是容易地構建項目,能夠包含 Webpack, Browserify, 或者 no build system。React在這方面也提供了create-react-app,可是如今還有一些侷限性:
注意這些限制是故意設計的,這有它的優點。例如,若是你的項目需求很是簡單,你就不須要自定義生成過程。你能把它做爲一個依賴來更新。若是閱讀更多關於不一樣的設計理念。
React學習曲線陡峭,在你開始學 React 前,你須要知道 JSX 和 ES2015,由於許多示例用的是這些語法。你須要學習構建系統,雖然你能夠在技術上能夠用 Babel Standalone 來編譯代碼,可是不推薦用於生產。
Vue樣擴大後就像React,縮小後就像 Jquery。你須要作的就是把以下標籤放到頁面就行:
<script src="https://unpkg.com/vue/dist/vue.js"></script>
而後就可編寫Vue代碼並應用到生產中,而不用擔憂性能問題。
因爲起步階段不需學JSX,ES2015 或構建系統,因此創建應用花的時間會更少。
ReactNative能使你用相同的組件模型編寫有本地渲染能力的APP(IOS或Android)。能同時跨多平臺開發,對開發者是很是棒的。相應地,Vue和Weex會進行官方合做,Weex是阿里的跨平臺用戶界面開發框架,Weex 的 JavaScript 框架運行時用的就是Vue。這覺得着不只在瀏覽器,在 IOS 和 Android 上面也能夠用 Vue 來進行開發。
在如今,Weex 還在積極發展,成熟度也不能和 ReactNative 相抗衡。可是,Weex的發展是由世界上最大的電子商務企業的需求在驅動,Vue 團隊也會和 Weex 團隊積極合做確保爲開發者帶來良好的開發體驗。
Mobx 在 React 社區很流行,實際上在Vue也採用了幾乎相同的反應系統。在有限程度上,React + Mobx 也能夠被認爲是更繁瑣的 Vue,因此若是你習慣組合使用它們,那麼選擇 Vue 會更合理。
Due的一些語法和Angular的很類似(例如 v-if
vs ng-if
)。由於Angular是Vue早期開發的靈感來源。然而,Augular中存在許多問題,在Vue中已經獲得解決。
在 API 與設計兩方面上 Vue.js 都比 Angular 1 簡單得多,所以你能夠快速地掌握它的所有特性並投入開發。
Vue.js 是一個更加靈活開放的解決方案。它容許你以但願的方式組織應用程序,而不是在任什麼時候候都必須遵循 Angular 1 制定的規則,這使讓Vue能適用於各類項目。咱們知道把決定權交給你,是很是必要的,就是是爲何提供Webpack template,讓你用幾分鐘,去選擇是否用高級特性,好比熱模塊加載、linting 、
Css extraction 等等。
Angular 1 使用雙向綁定,Vue在不一樣組件間強制適用單向數據流。這使應用中的數據流清晰易懂。
在 Vue 中指令和組件分得更清晰。指令只封裝 DOM 操做,而組件表明一個自給自足的獨立單元 —— 有本身的視圖和數據邏輯。在 Angular 中二者有很多相混的地方。
Vue.js 有更好的性能,而且很是很是容易優化,由於它不使用髒檢查。
在Angular 1中,當 watcher 愈來愈多時會變得愈來愈慢,由於做用域內的每一次變化,全部 watcher 都要從新計算。而且,若是一些 watcher 觸發另外一個更新,髒檢查循環(digest cycle)可能要運行屢次。 Angular 用戶經常要使用深奧的技術,以解決髒檢查循環的問題。有時沒有簡單的辦法來優化有大量 watcher 的做用域。
Vue.js 則根本沒有這個問題,由於它使用基於依賴追蹤的觀察系統而且異步列隊更新,全部的數據變化都是獨立地觸發,除非它們之間有明確的依賴關係。
有意思的是,Angular 2 和 Vue 用類似的設計解決了一些 Angular 1 中存在的問題。
Augluar 2徹底是一個全新的框架。例如,它具備優秀的組件系統,而且許多實現已經徹底重寫,API也徹底改變了。
Angular 1面向的較小的應用程序,Angular 2已轉移焦點,面向的是大型企業應用。TypeScript被引用,這對那些喜歡用Java或者C#等類型安全的語言的人是很是有用的。
Vue也適合企業應用,也可使用TypeScript來支持官方類型和用戶貢獻的類型,儘管這是可選的。
在性能方面,這兩個框架都是很是快。可是若是你查看第三方參照,就能夠得出 Vue 2 比 Angular2 要快的。
在尺寸方面,雖然 Angular 2 使用 tree-shaking 技術和編譯技術能使代碼尺寸減少。
即使包含編譯器和所有功能 Vue2(23kb)比起 Angular 2(50kb)仍是小的多。可是要注意,用 Angular 的 App 的尺寸縮減是用 tree-shaking 移除了那些框架中沒有用到的功能,當隨着引入功能的增多,尺寸會愈來愈大。
Vue 官方提供了構建工具,但沒限制你如何構建。有人喜歡用統一的方式構建,也有不少開發者喜歡這種靈活自由的方式。
開始使用Vue,你使用的是熟悉的HTML、符合ES5規則的JavaScript(也就是純JavaScript)。有了這些基本的技能,你能夠快速地掌握它(指南)並投入開發 。
Angular 2 的學習曲線是很是陡峭的。即便不包括TypeScript,它們開始指南中所用的就有ES2015標準的JavaScript,18個NPM依賴包,4個文件和超過3千多字介紹,這一切都是爲了完成個Hello World。而Vue's Hello World就很是簡單。
Ember 是一個全能框架。它提供大量的約定,一旦你熟悉了它們,開發會很高效。不過,這也意味着學習曲線較高,並且不靈活。在框架和庫(加上一系列鬆散耦合的工具)之間權衡選擇。後者更自由,可是也要求你作更多的架構決定。
也就是說,最比如較 Vue.js 內核和 Ember 的模板與數據模型層:
Vue 在普通 JavaScript 對象上創建響應,提供自動化的計算屬性。在 Ember 中須要將全部東西放在 Ember 對象內,而且手工爲計算屬性聲明依賴。
Vue 的模板語法能夠用全功能的 JavaScript 表達式,而 Handlebars 的語法和幫助函數語法相比之下很是受限。
在性能上,Vue 甩開 Ember 幾條街,即便是 Ember2.0 的最新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不須要依賴polyfills來工做,最低到IE9。
在 Polymer 1.0版本中,爲了彌補性能,團隊很是有限的使用數據綁定系統。例如,在Ploymer中支持的惟一表達式只有布爾值否認和單一的方法的調用,它的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 2.0 提供了一個相似於基於組件的開發模型(在Riot中稱之爲」Tag」),提供小巧精美的API。Riot 和 Vue 可能共享一些設計理念。即便相比Roit重一點,Vue仍是有不少顯著優點的: