react.js,angular.js,vue.js學習哪個好？

現在的前端框架層出不窮，作為前端開發者何去何從？fackbook的react.js盛世火熱，react native打開了JS佔領android和ios領地，讓JS變的無所不能。angular.js背後有谷歌，個人感覺太重了，相對而言更喜歡vue,但是實際選擇哪個更好呢？總不能一下都學了也沒這個精力啊

---

謝謝邀請，這個問題我要認真回答一下，盡量不帶主觀偏向。

我們學一個東西，通常兩個目的：

- 為了解決現有的問題

- 為了解決將來可能會有的問題

所以，在學這些東西之前，先必須了解，它們是用來解決什麼問題的。

Angular，React，Vue，這三者其實面對的是同一個領域，那就是Web應用，什麼是Web應用呢，我之前有一篇大致講了：構建單頁Web應用 · Issue #5 · xufei/blog · GitHub

這三者中，Angular的適用領域相對窄一些，React可以拓展到服務端，移動端Native部分，而Vue因為比較輕量，還能用於業務場景非常輕的頁面中。

在Web應用中，我們需要解決的問題可以歸納為三類：

- 狀態

- 組織

- 效率

1. 狀態

什麼是狀態？

在一個業務界面中，我們可能會根據某些數據去生成一塊界面，然後通過界面上的某些操作，改變一些數據，從而影響界面的另外一些部分。

這裡面就存在兩種關係，一種是從數據到界面，一種是從界面到數據。能夠描述界面當前狀況的數據，就可以被稱為狀態。

如果不對狀態作抽象，很可能會導致邏輯的混亂，比如說，一個地方點了，要改多個地方，這種代碼直接寫，很容易寫亂的，所以，不同的框架採用不同的方式進行了處理。

比如說MVVM流的Angular和Vue，還有Avalon，Regular，Knockout，都是走的這一流派，通過類似模板的語法，描述界面狀態與數據的綁定關係，然後通過內部轉換，把這個結構建立起來，當界面發生變化的時候，按照配置規則去更新相應的數據，然後，再根據配置好的規則去，從數據更新界面狀態。

React走的是另外一個流派，就是所謂的函數式，在這個裡面，推崇的是單向數據流：給定原始界面（或數據），施加一個變化，就能推導出另外一個狀態（界面或者數據的更新）。

在這裡需要額外提一下ReactiveJS，它的理念又有所不同，是基於Reactive的。

2. 組織

剛才這些，都可以看作是滿足最基本的需求，那就是業務的正確性。在這之後，就有另外的訴求了，首當其衝的就是整個業務代碼的組織。

所謂組織，指的是兩個方面，一方面是模塊關係，另一方面是業務模型。

我們是怎樣解決模塊關係的呢？共識就是組件化。整個應用形成倒置的組件樹，每個組件提供對外介面，然後內部只關注自己的實現。這些東西說起來簡單，但實際做的時候還是有非常多需要考慮的東西，包括組件的定義，約束，管理，測試等等，而在Web這個體系中，組件化也有一些不太適合的場景，需要做一些權衡，這方面詳細說就比較複雜了，需要好多篇幅才能說清楚，可以看看我這篇：Web應用組件化的權衡 · Issue #22 · xufei/blog · GitHub

那麼，業務模型又是指什麼呢？我們提到React的時候，就會聽到Flux，Redux之類的東西，為什麼又要有它們呢？我們必須認識到，脫離了這類東西，純上層的組件化是不牢固的，如果你感受不到，只有一個原因：你的項目的業務層太薄。

業務模型指的是所處領域中的業務數據、規則、流程的集合。即使拋開所有展示層，這一層也是應當要能夠運作起來的。

那麼，這跟Redux之類又有什麼關係呢？

我們剛才提到組件化，整個應用形成了一個組件樹，組件之間可能會需要通訊，它們通訊的內容可能是簡單的界面事件，也可能是業務含義較深，能夠牽一髮而動全身的。界面是怎麼來的？是由初始界面加上狀態形成的，為了能夠反映界面的變化，我們必須使得對業務模型的每一個擾動都收斂到確切的狀態，所以，這也就是Redux這類東西的意義所在。

所以，沒有Redux之類輔助方案的React，是不完整的。而Redux本身，也不是局限到只能作為React輔助方案的，它的理念，對於Angular，Vue，照樣是非常重要的補充。在同一業務場景下，對於每個框架來說，數據模型層面臨的問題都是一樣的，在這一層並沒有任何分別。

另外，Angular 2中引入了RxJS，這個東西處理這方面也是有很大優勢的。

在這裡我要插一句自己的想法，很多學習能力較強的朋友，當他發現FP，FRP之類編程模型的時候，會非常喜歡，但對於大型項目，需要很多人協作的狀況來說，不一定是好事。

用面向過程，面向對象的那些方式，雖然笨重，但好處是門檻低，符合大多數人的理解和思維方式，並且可以復用幾十年積累的各種設計模式和經驗。所以，如果不是小而精悍的團隊，我對引入FP和FRP都是比較保守的。

在這些東西下層，還有Relay，GraphQL等等致力於業務模型同步的方案，但這個引入代價同樣是非常大。

再插另外一句：很多人吐槽Angular大而全笨重，吐槽React全家桶，但其實世界上大部分人是沒有框架整合能力的，小而美的庫最後整合了，在面臨各種業務需求之後不斷引入新模塊，也還是一個大而全的方案。在絕大部分場景下，還是有一整套標配模塊比較好。你看ExtJS他也單獨提供ExtCore模塊，但不但競爭不過jQuery，連mootools和prototype都競爭不過，用它的人幾乎都是用全方案的。

3. 效率

效率也分兩種，一種是開發效率，一種是運行效率。

我們前面提到，組件化，這是提升開發效率的一種手段，在組件化這個點上，各路框架的組織方式大同小異，反正最終都是組件樹。

具體到單個組件的實現上，我個人是傾向於MVVM流的，之前 @題葉 做過對比，MVVM系的代碼量會少一些，開發效率稍高一點。

其中，Angular因為實現的特殊性，有作用域繼承之類的雙刃劍黑魔法，開發效率的不穩定因素要高不少，深刻理解的人用起來效率很高，不理解的用了到處是坑。

再看運行效率，這裡面，Angular是較低的那個，主要在於數據變更檢測方式，但這也不是絕對的，在部分場景下，臟檢測未必就沒有優勢，這個記得 @鄭海波論述過。

運行效率的另外一面主要是創建和修改DOM，在創建上，大家是沒有太大差異的，而在修改DOM的時候，React首創的虛擬DOM有很大優勢，所以其他框架內部實現也在逐漸借鑒。

（我之前有個對虛擬DOM的回答是有偏差的，稍後去更新）

========

如果看到這裡，很可能你會疑惑，題目問的明明是學哪個好，我說這些是什麼意思？

我用這些篇幅說明了Web應用的業務開發中存在哪些麻煩，每種技術又是來解決什麼痛點的，這樣，你可以按照自己的需求去，結合業務場景進行分析，然後選擇需要的挨個學下去。

其實學API之類的很快，還是要把自己業務中的難點想清楚，帶著問題去學，帶著需求去學，學思想重於學使用，一定能事半功倍。

---

這個問題，我前不久剛在 Quora 答了個幾乎一模一樣的，不想再翻譯一遍了，真想看就當學英文吧：https://www.quora.com/Which-should-I-learn-Mithril-Vue-or-Angular/answer/Evan-You-3

概括一下就是，想要只學一個一勞永逸，那是不可能的。好好打基礎，然後多嘗試不同風格的框架，因為只有嘗試過後才能理解比如 @徐飛 提到的各種權衡，也只有嘗試過後才能知道哪個能真正提升自己的開發效率。說沒精力，那是借口。

如果你不是專業前端，那就用 Vue 吧！哈哈哈

---

下面只是我的個人觀點，如果不喜歡可以忽略。

如果你只有時間學習一樣，很簡單，學習React.js最好。

我研究過Angular和Vue，和React也做過對比，都是很不錯的工具，都有各自的優點，但是最終我選擇主攻React，一個重要原因，是React的社區里，無論是Facebook的React核心團隊還是開源社區的貢獻者，都信奉一點（至少潛意識裡信奉一點）哲學，那就是「限制」（Constraint）是很重要的一個特性。這裡「限制」並不是貶義詞，是褒義詞，因為對於大部分應用開發者來說，無論怎麼苦口婆心地勸誡他們用什麼best practice都沒用，只有施加「限制」，才能讓Code可維護易於管理。

對於Angular好Vue，就我個人理解，並沒有像React世界那樣施加很強的「限制」，所以，只學一樣就學React。

我寫了一個專欄 進擊的React - 知乎專欄 ，專門來講React。

---

之前在專欄里寫了一篇關於技術遠型的文章《第四章：如何選擇合適的前端框架，告別選擇恐懼症》，鏈接：知乎專欄

將 package.json 中的 Ionic 版本改為 2.0.0 的時候，我就思考一個問題。這個該死的問題是——我到底要用哪個框架繼續工作下去。

剛開始學習前端的時候，SPA（單頁面應用）還沒有現在這麼流行，可以選擇的框架也很少。而今天，我隨便打開一個技術相關的網站、應用，只需要簡單的看幾頁，就可以看到豐富的前端框架世界 Angular 2、React、Vue.js、Ember.js。

當我還是一個新手程序員，我從不考慮技術選型的問題。因為不需要做技術選型、不需要更換架構的時候，便覺得框架豐富就讓它豐富吧，反正我還是用現在的技術棧。等到真正需要用的時候，依靠之前的基礎知識，我仍能很輕鬆地上手。

可是一旦需要考慮選型的時候，真覺得天彷彿是要塌下來一般。選擇 A 框架，則使用過 B 框架的可能會有些不滿。選用 B 框架，則使用 A 框架的人會有些不滿。選擇一個過時的框架，則大部分的人都會不滿。這點「小事」，也足夠讓你幾天幾夜睡不了一個好覺。

前端的選擇恐懼症

年輕的程序員都是好奇的貓，玩過一個又一個的前端框架。從毛球上弄出一條條的線，玩啊玩，最後這一個個的框架在腦子裡攪漿糊。

技術選型：不僅僅受技術影響

有太多的選擇，就是一件麻煩的事；沒有選擇時，就是一件更麻煩的事；有唯一的選擇時，事情就會變得超級簡單。

倘若，我是那個使用 Java 來開發 API 的少年，我會使用 Spring Boot 來作為開發框架。儘管 Java 是一門臃腫的語言，但保守的選擇不會犯上大錯。

倘若，我是那個使用 Python 來開發 Web 應用的少年，我會使用 Django 來作為開發框架。它可以讓我快速地開發出一個應用。

只可惜，我不再是一個後台開發者，我不再像過去，可以直接、沒有顧慮的選擇。當我選擇 JavaScript 時，我就犯上了「選擇恐懼症」。技術選型也是沒有銀彈的——沒有一個框架能解決所有的問題。

在《Growth：全棧 Web 開發思想》一書中，我曾提到過影響技術選型的幾個因素。

這時，為了更好的考量不同的因素，你就需要列出重要的象限，如開發效率、團隊喜好等等。並依此來決定，哪個框架更適合當前的團隊和項目。

即使，不考慮前端框架以外的因素，那麼技術選型也是相當痛苦的一件事。

上線時間影響框架

每一個框架從誕生到受歡迎，都有其特定的原因和背景。不同的開發者選擇時，也是依據於其特定情景下的原因和背景。

如 Ruby On Rails誕生之時，帶來了極大的開發效率，而開發效率正是當時大部分人的痛點。我們知道 Ruby On Rails 是一個大而廣的框架，它可以提供開發者所需要的一切，開發者所需要做的就是實現業務代碼。當開發效率不再是問題時，自由度變成了一些開發者的痛點，此時像 Sinatra 這樣的微框架就受這些人歡迎。

也因此，開發效率會在很大程度上影響技術選型。畢竟，開發效率在很大程度上決定了上線時間，上線時間很大地影響了技術選型。

• 用幾星期的時間來做一個網站，我首先想到的會是找一個模板。
• 用幾個月的時候來做一個網站，我仍然會想到找一個框架。
• 用幾個年的時間來做一個網站，我會想著是不是可以造幾個輪子。

遺憾的是，要遇到可以造輪子的項目不多。

鎚子定律：你需要更大的視野

年輕的時候，學會了 A 框架，總覺得 Z 網站用 A 框架來實現會更好，一定不會像今天這樣經常崩潰、出Bug。**時間一長，有時候就會發現，Z 網站使用 A 不合適，他們的問題並不是框架的問題，而是運維的問題。

後來，出於對職業發展的探索，我開始了解諮詢師，看到一本名為《諮詢的奧秘》的書籍。在這其中，提到一個有意思的定律「鎚子定律」（又稱為工具定律）——聖誕節收到一把鎚子的孩子，會發現所有東西都需要敲打。 出現這種情況的主要原因是，開發者對一個熟悉的工具過度的依賴。

認真觀察，就會發現這個現象隨處可見。當一個新手程序員學會了某個最新的框架，通常來說這個框架有著更多的優點，這個時候最容易出現的想法是：替換現有的框架。可是，現有的框架並沒有什麼大的問題。並且憑估不充分時，新的框架則存在更多的風險。

並且，對於某個熟悉工具的過度依賴，特別容易影響到技術決策——看不到更多的可能性。這時候，我們就需要頭腦風暴。但是這種情況下，頭腦風暴很難幫助解決問題。

在這個時候，擁有更多項目、框架經驗的人，可能會做出更好的選擇。

前端框架一覽

在這個複雜的前端框架世界裡，我不敢自稱是有豐富的徒刑經驗。我只能去分享我用過的那些框架，讀者們再結合其他不同的框架來做決定。

jQuery, 使用生態解決問題

jQuery 創立之初的主要目標是，簡化 HTML 與 JavaScript 之間的操作，開發者可以輕鬆地使用 $("elment").doSomething() 的形式來對元素進行操作。

誕生之後，由於其簡單容易手、並且擁有豐富的插件，幾度成為最受歡迎的前端框架。大部分動態交互效果，都能輕鬆地找到 jQuery 插件。即使，沒有也能通過其 API，快速地編寫相應的插件。

在很多人看來，jQuery 似乎是一個不會在未來用到的框架。可惜到了今天（2017年），我仍然還在項目中使用 jQuery 框架。一年前，我們仍在一個流量巨大的搜索網站上使用用 jQuery。在這幾個項目上，仍然使用 jQuery 的原因，大抵有：

• 項目功能比較簡單。並不需要做成一個單頁面應用，就不需要 MV* 框架
• 項目是一個遺留系統。與其使用其他框架來替換，不如留著以後重寫項目

所以，在互聯網上仍有大量的網站在使用 jQuery。這些網站多數是 CMS（內容管理系統）、學校網站、政府機構的網站等等。對於這些以內容為主的網站來說，他們並不需要更好的用戶體驗，只需要能正確的顯示內容即可。

因此即使在今天，對於一般的 Web 應用來說，JavaScript 搭配 jQuery 生態下的插件就夠用。然而，對於一些為用戶提供服務的網站來說，前端就不是那麼簡單。

Backbone.js，脊椎連接框架

從 Ajax 出現的那時候開始，前端便迎來了一個新的天地。後來，智能手機開始流行開來。Web 便從桌面端往移動端發展，越來越多的公司開始製作移動應用（APP 和 移動網站）。jQuery Mobile 也誕生這個特殊的時候，然而開發起中大型應用就有些吃力。隨後就誕生了 Backbone、Angular 等等的一系列框架。

畢竟，作為一個程序員，如果我們覺得一個工具不順手，那麼應該造一個新的輪子。

Backbone.js 是一個輕量級的前端框架，其編程范型大致上匹配MVC架構。它為應用程序提供了模型(models)、集合(collections)、視圖(views)的結構。

Backbone 的神奇之處在於，在可以結合不同的框架在一起使用。就像脊椎一樣，連接上身體的各個部分。使用 Require.js 來管理依賴；使用 jQuery 來管理 DOM；使用 Mustache 來作為模板。它可以和當時流行的框架，很好地結合到一起。在今天看來，能結合其他前端框架，是一件非常難得的事。

遺憾的是，Backbone.js 有一些的缺陷，使它無法滿足複雜的前端應用，如 Model 模型比較簡單，要處理好 View 比較複雜。除此，還有更新 DOM 帶來的性能問題。

Angular，一站式提高生產力

與 Backbone 同一時代誕生的 Angular 便是一個大而全的 MVC 框架。在這個框架里，它提供了我們所需要的各種功能，如模塊管理、雙向綁定等等。它涵蓋了開發中的各個層面，並且層與層之間都經過了精心調適。

我們所需要做的便是遵循其設計思想，來一步步完善我們的應用。Angular.js 的創建理念是：即聲明式編程應該用於構建用戶界面以及編寫軟體構建，而命令式編程非常適合來表示業務邏輯。

我開始使用 Angular.js 的原因是，我使用 Ionic 來創建混合應用。出於對製作移動應用的好奇，我創建了一個又一個的移動應用，也在這時學會了 Angular.js。對於我而言，選擇合適的技術棧，遠遠比選擇流行的技術棧要重要得多，這也是我喜歡使用 Ionic 的原因。當我們在製作一個應用，它對性能要求不是很高的時候，那麼我們應該選擇開發速度更快的技術棧。

對於複雜的前端應用來說，基於 Angular.js 應用的運行效率，仍然有大量地改進空間。在應用運行的過程中，需要不斷地操作 DOM，會造成明顯的卡頓。對於 WebView 性能較差或早期的移動設備來說，這就是一個致命傷。

幸運的是在 2016 年底，Angular 團隊推出了 Angular 2，它使用 Zone.js 實現變化的自動檢測、

而遲來的 Angular 2 則受奧斯本效應[osborne]的影響，逼得相當多的開發者們開始轉向其它的框架。

[osborne]: 頗受歡迎的個人電腦廠商奧斯本，其公司的創新式便攜電腦還沒有上市，就宣布他們要推出的更高檔的機器，而又遲遲無法交貨，消費者聞風紛紛停止下單訂購現有機種，最後導致奧斯本因收入枯竭而宣布破產。

React，組件化提高復用

從 Backbone 和 Angular.js 的性能問題上來看，我們會發現 DOM 是單頁面應用急需改善的問題——主要是DOM 的操作非常慢。而在單頁面應用中，我們又需要處理大量的 DOM，性能就更是問題了。於是，採用 Virtual DOM 的 React 的誕生，讓那些飽受性能苦惱的開發者歡迎。

傳統的 DOM 操作是直接在 DOM 上操作的，當需要修改一系列元素中的值時，就會直接對 DOM 進行操作。而採用 Virtual DOM 則會對需要修改的 DOM 進行比較（DIFF），從而只選擇需要修改的部分。也因此對於不需要大量修改 DOM 的應用來說，採用 Virtual DOM 並不會有優勢。開發者就可以創建出可交互的 UI。

除了編寫應用時，不需要對 DOM 進行直接操作，提高了應用的性能。React 還有一個重要思想是組件化，即 UI 中的每個組件都是獨立封裝的。與此同時，由於這些組件獨立於 HTML，使它們不僅僅可以運行在瀏覽器里，還能作為原生應用的組件來運行。

同時，在 React 中還引入了 JSX 模板，即在 JS 中編寫模板，還需要使用 ES 6。令人遺憾的是 React 只是一個 View 層，它是為了優化 DOM 的操作而誕生的。為了完成一個完整的應用，我們還需要路由庫、執行單向流庫、web API 調用庫、測試庫、依賴管理庫等等，這簡直是一場噩夢。因此為了完整搭建出一個完整的 React 項目，我們還需要做大量的額外工作。

大量的人選擇 React 還有一個原因是：React Native、React VR 等等，可以讓 React 運行在不同的平台之上。我們還能通過 React 輕鬆編寫出原生應用，還有 VR 應用。

在看到 Angular 2 升級以及 React 複雜性的時候，我相信有相當多的開發者轉而選擇 Vue.js。

Vue.js，簡單也是提高效率

引自官網的介紹，Vue.js 是一套構建用戶界面的漸進式框架，專註於MVVM 模型的 ViewModel 層。Vue.js 不僅簡單、容易上手、配置設施齊全，同時擁有中文文檔。

對於使用 Vue.js 的開發者來說，我們仍然可以使用 熟悉的 HTML 和 CSS 來編寫代碼。並且，Vue.js 也使用了 Virtual DOM、Reactive 及組件化的思想，可以讓我們集中精力於編寫應用，而不是應用的性能。

對於沒有 Angular 和 React 經驗的團隊，並且規模不大的前端項目來說，Vue.js 是一個非常好的選擇。

雖然 Vue.js 的生態與 React 相比雖然差上一截，但是配套設施還是相當齊全的，如 Vuex 、 VueRouter。只是，這些組件配套都由官方來提供、維護，甚至連 awesome-vue 也都是官方項目，總覺得有些奇怪。

除此，Vue.js 中定義了相當多的規矩，這種風格似乎由 jQuery 時代遺留下來的。照著這些規矩來寫代碼，讓人覺得有些不自在。

和 React 相似的是，Vue.js 也有相應的 Native 方案 Weex，仍然值得我們期待。

小結知乎專欄

除了上面提到的這些前端框架，我還用過 Reactive、Ember.js、Mithril.js，遺憾的是同 Vue.js 一樣，我沒有在大一點的、正式項目上用過。也因此，我沒有能力、經驗、精力去做更詳細的介紹。有興趣的讀者，可以做更詳細的了解，也可以在 GitHub (phodal/fe) 上給我們提交一個 Pull Request。

總結

今天，大部分的框架並不只是那麼簡單。為了使用這個框架你，可能需要學習更多的框架、知識、理論。一個很好的例子就是 React，這個框架的開發人員，引入了相當多的概念，JSX、VIrtual Dom。而為了更好地使用 React 來開發，我們還需要引入其他框架，如 Redux、ES6 等等的內容。

這些框架從思想上存在一些差異，但是它們都有相似之處，如組件化、MV**、All in JS、模板引擎等等。欲知後事如何，請期待每周一更的《我的職業是前端工程師》：知乎專欄。

---

學基礎，寫代碼，直到你覺得同時學了這三個就跟玩一樣

---

樓上很多大佬都說過了,我就不贅述了.

但是要提個醒,警惕有些偏樓的人的說法"你JavaScript原生基礎練到NB無敵,你學這三框架就跟玩一樣"

這種無比正確的廢話太多見了,就跟當初我看到一個問題--"學前端要先學c/c++,還是直接學JavaScript?"

有大神出現"先學c++,c++包羅萬象,是所有高級語言的基礎,你JavaScript引擎都是c++寫的,c++這麼基礎這麼包羅萬象的語言你學好了,學JavaScript不跟玩一樣?"

```輪包羅萬象,我為啥不去學scala?,而且我覺得學彙編甚至機器碼更基礎,多有語言不都是要通過機器碼來實現嗎?

````照此理論,我建議先別學react vue,樓主你先學機器碼吧,學會了,其他別說前端這些框架了,什麼scala rust c++ 都是紙老虎啊.

---

推薦：《前端開發框架簡介:angular和react 》

react是facebook推出一個用來構建用戶界面的js庫。官方介紹的三大特性如下：

just the ui

把react只當作一個ui組件就好，等同於傳統mvc中的view。

virtual dom

react在編程模型和傳統dom之間添加了一層，稱之為虛擬dom。好處非常多，性能更好，可以在node環境下完成渲染（解決seo問題），可以更好的用於開發native apps。

data flow

反應式的單向數據綁定，比傳統數據綁定更簡單，簡單的使用js事件觸發改變組件狀態也可以實現雙向綁定的效果。

什麼是angularjs

angularjs是google推出的一個前端js框架，面世已有幾年時間，非常成熟，目前已經有非常多的第三方模塊，基本上可以解決前端工程領域的各方面的問題。網上的資料也非常多，這裡就不做過多介紹。

reactjs和angularjs

reactjs是非常純粹的組件式開發，所有的頁面元素均由各大小組件組合而成。再插上虛擬dom的翅膀，實現了一處代碼多平台執行的效果，關鍵是這貨性能還不錯。但是呢，除了組件以外，這貨其他什麼功能也沒有，你需要重新造出所有的缺失的輪子或者選擇第三方的輪子。

angularjs則是一個完整的框架，意味著不需要太多的工作，就可以使用於大部分的業務場景。
簡單好用的module和依賴注入系統，controller中定義的數據和事件，service實現不同組件之間共享數據，filter處理篩選數據，forms支持表單和複雜的表單驗證，簡單的動畫模塊animations，強大的directive實現指令和指令的嵌套，可以很輕鬆的實現reactjs的組件及組件組合功能。ui組件有bootstrap for angular，路由有ui-router，還有promise模塊$q，還有原生的$resource模塊直接支持標準的restful介面，集成的單元測試，等等，哇哇，功能好多的樣子，又到但是的環節，話說很多初學者會被很多angularjs的名詞折磨的暈頭轉向。。。

如果要拿reactjs來開發應用，你還需要做很多額外的工作。而如果使用angularjs的話，就可以直接開始工作了。

兩者之間其實無法直接拿來比較，畢竟react只是view的解決方案，而angularjs是包含mv*的完整框架。

拋開跨平台和性能因素，就功能而言，angularjs已經包含了reactjs的功能，只需要一個自定義directive加controller就可以輕鬆實現組件效果。

如果是一個大型項目，使用angularjs無疑更可靠。強大的功能帶來一定的學習成本，但這一切都是值得的。
而使用react的話，你首先需要考慮一個問題，數據怎麼管理？用哪個mvc庫？接下來還有一堆問題等著你。

如果只是一個小型項目，那就看心情吧。

再單獨說下關於數據的問題，react還搞出了一個叫做flux的概念。簡單看了一下react的flux模型，這不就是個觀察者模式嘛。而angular至少支持了三種數據共享方式，包括service，事件，rootScope直接添加一個object，可以分別適應各種不同的場景。

我們來看看react和angular實現組件的方式有什麼不一樣。。

了解更多，請至 《前端開發框架簡介:angular和react 》

此外，小編從騰訊雲技術社區為大家精選3篇Vue.js文章，讓大家對Vue.js有一個初步認識，以方便大家判斷選擇。

包學會之淺入淺出Vue.js：開學篇

包學會之淺入淺出Vue.js：升學篇

包學會之淺入淺出Vue.js：結業篇

---

如果將來的項目我有的選，應該選擇和web component標準更一致的庫或者框架。從這個角度，比較：

&

& （1）


和

var SearchComponent = React.createClass(...)
var mySearchComponent = new SearchComponent(...)
mySearchComponent.render(...) （2）


能以簡單的HTML為介面的組件化（1）比以JS驅動的組件化（2）更好。尤其是對設計人員，意義重大。可讀性，甚至美學的角度來說，（1）都比（2）好很多，想像一下一個中大型項目，你更願意維護哪種代碼？

另一方面，比較：

&

& （1）


和

&& （3）


我還是覺得（1）比（3）好，儘管表面看似乎只是語意化的差別。不過其實語意挺重要的，語意就是抽象層次，果斷明了的語意意味著可讀可維護性，幾行代碼看不出來，幾萬行就不同了。

（2）是React的哲學，因為他依賴Virtual DOM的JS實現來優化，被Render的東西要經過一層JS，所以整個Component的概念是以JS為核心的。坦白說如果一個框架要componentize，我不希望再去糾結Javascript，對設計與開發的意義我前面已經說了。

另外，絕大多數的桌面Web App不需要Virtual DOM的性能，Mobile Web App可能相關大一點，我想這是很多團隊選擇React Native的原因，畢竟他可以編譯成原生App。否則如果是一個開始頁，一個列表，一個detail頁這樣簡單的應用，我寧可選擇Ionic 2這樣的Hybrid方案，原型要方便很多。

（3）是vue，相比React，我更喜歡他的簡單。React作為一個Library，時不時有人問Flux的本質是什麼這種問題，Flux不是React的一部分，但一個庫做出來是為了體現某種架構優越性呢，還是服務於開發者的實際開發，不要忽略世界上只有一家Facebook這個事實。用vue你不會有這種概念負擔，不需要糾結那麼多高大上的概念。

web Component是未來，React，vue提供了各自的解決方案，但還不是真正意義上的web component。

這是基於Angular 2實現的ionic 2的一個搜索框組件

// 介面
&
&

// 實現
Compoent({
template: ``
})
export class SearchBar {
...
}


這才是web component，Angular 2綁定語法會讓初學者感到奇怪，不過整個Component的引用仍然是valid HTML。Angular 2以這個模型為基礎拓展了實際開發中需要的功能。

總的來說，React和vue各自提供了很好的Component化開發的解決方案，但Angular 2推進的是標準本身。

如果你有的選，應該學Angular 2。

---

瀉藥：

1. 從技術本身緯度去思考問題，簡直就是自尋死路，因為存在即合理；

2. 考慮以動態的眼光看技術，試著把自己放到3年後，3年後哪個倉庫的代碼提交頻率依舊很活躍？能持續保持活躍的原因是多方面的，jQuery倉庫現在還非常活躍，當然不是因為純技術緯度的jQuery就比其他類似的庫好；

3. 所以這是關於社區的事情，哪個社區你更看好？目前來說React的確是優勢明顯，也算是ReactNative強力助攻吧；

4. 同樣無關技術：作為亞洲第二的淘寶前端團隊，我們用React組件標準，不完全統計阿里一半以上的團隊都有在重度使用React；

以上觀點僅代表個人。。。！

---

年輕人，我跟你講，只看api和文檔友好度就行了，別的東西都是不透明升級的，研究了也無法左右生活。XD

（很多時候人們比較技術都是比較現狀，但其實都在發展，我們同時應該比較幾種路線的理論上限，即再改就不是同一個東西了。那麼這個變化背後的不變者是什麼呢？我認為，權宜的做法，是看api是否直觀。無物常駐，唯api不破（對項目是高耦合侵入式的）。）

當然是Vue啊。除非你要爛在技術無窮盡的純量上的優化提升的坑裡，否則除了清爽的api和學習文檔，別的又操啥心呢？

---

不談應用場景就談框架都是耍流氓……

學好JS才是王道，JS會了，這些框架分分鐘上手……剩下就是查查文檔了……

---

2017-04-26 補充：

最近換了個公司，到了美圖。用了兩個晚上完全上手了vue、vue-router、vuex。終於可以對vue進行評論了。
首先，vue確實是一個很好上手的框架，文檔齊全，介紹也合理。開發工具齊全，整體開發體驗不錯。
因為，我的觀點一直是，技術是為了生產更好的產品，所以網上很多人說vue借鑒（react、angular）什麼的，我並不在意，所以，不影響我學習他。
就我對這三個vue、angular、react的了解，vue是這三個中最好上手的框架。
也許是借鑒的原因，在vue上確實可以找到很多angular、react的影子。但是，進行了許多優化，所以理解起來也更容易。

------------------------

不一樣的框架Angular2.0是強化html語法，Angular2.0的模板引擎非常強大。 React強化js，有人提建議說React要是可以加上模板引擎語法就好了，我是不太認同的。當你真正理解React的時候你就會體會到它的優點.......

一、angular

用angular cli 搭建環境（一步到位）angular/angular-cli，加上官方文檔（基本有實例）基本可以做項目了。

個人最喜歡angualr2 有3點：

（1）、組件間的相互通訊，通過ViewChild可以訪問引用組件的內部屬性、方法。通過EventEmitter可以調用父組件的方法，簡直太方便了。寫起通用組件簡直是得心應手。

（2）、模板引擎[class.class-active]、[hidden]等等，還有內置的那些指令*ngIf、*ngFor等等。你會愛上這種寫法的。

（3）、寫angular2請用上TypeScript；雖然從javascript轉過來對於強類型控制有時候會覺得挺繁瑣的。但是它確確實實能給我們提供很多有便利，比如angualr的表單。所以，務必、一定要用TypeScript。

至於雙向綁定什麼的，基本上每個上手angular的人都會馬上去了解，我就不說了。

很多人說angualr很重，但是這個重是在於它給你提供了一切你想要、或者說你可能會用到的庫（比如：react中做http通訊，那你就必須引入第三方的庫如 isomorphic-fetch 等等，然而，在angualr2中直接提供了http庫@angular/http；再比如：react中路由，那你需要引入react-router，然而在angular2中直直接提供了Router功能，angualr 2 官方文檔是我見過的最完善的文檔，還配套了那麼多可運行的實例，太貼心了，好好閱讀必然有收穫）。
然後，用angualr寫動畫簡直太方便了，甩react兩條街（雖然我一直是react的擁護者，但是用react寫起動畫來好痛苦）
這裡有基於angular2.0搭建的小程序（大家可以參見）：

coocssweb/angular-mobile

最後，可能是因為剛上手沒有做過完整項目原因，感覺angular寫到後面，業務複雜了，邏輯複雜了，一個頁面的代碼會越來越多.......也許是我模塊化得不夠細吧。

二、react

react其實上手不會複雜。但是依稀記得很久以前剛開始學react的時候，配置環境要了我半條命（特別是有些npm包要instal半天的時候，基本上快奔潰了.....l ）。

我想學剛開始了解reac都會了解到它的虛擬dom，然而這些對於初學者來說太飄飄然了。

說說我用react的感受吧。

（1）組件模塊化，用React會很容易讓你想細化你的模塊，讓你的頁面代碼非常的精簡。比如一個List頁面，至少可以分 List、Item、Pager等等幾個細化的模塊（react文檔上介紹的複合組件）。

（2）CSS模塊化，在用React時，一般每個組件都會建一個對應的CSS文件，而你不用擔心這些CSS裡面的命名會相互影響。可以通過在webpack中配置css生成的命名規範，從而讓你的這些CSS頁面在最終構建的時候不會互相影響。當然，難免需要一些共用的CSS，而這個時候你可以用composes的方式進行共用；詳細請參見 如何在 React 中運用 CSS？

（3）數據流處理，一開始我是用了一段時間的Flux，挺喜歡它的單項數據流模式。但是特別討厭我必須在每個頁面內添加監聽，來監聽數據變化，然後重新渲染頁面。

當看到，Redux的時候，思想上瞬間高潮了。通過redux你可以完全實現View組件和邏輯組件的分離（Container） 通過在container組件里connect 來鏈接[ store、action] 和 view組件間的關聯。就可以實現到View組件確確實實的是乾淨的react組件，只做頁面上的一些布局和邏輯；container組件負責store、action轉化為props讓view組件調用。這樣組件都是乾淨的。

Redux的非同步數據請求上的處理，自己封裝一個基礎類。然後就可以實現下面的這種寫法;完全可以大大加快你的開發效率

//GET_LEAD_LIST_REQUEST、GET_LEAD_LIST_SUCCESS、REQUEST_ERROR 為Action Type
//分別處理，開始請求、請求成功、請求出錯
export function getLeadList_(params) {
return {
assembleMode: SINGLE_REQUEST_MODE,
actionTypes: [ GET_LEAD_LIST_REQUEST, GET_LEAD_LIST_SUCCESS, REQUEST_ERROR ],
service: () =&> leadService.getLeadList(params)
}
}


（4）關於React Native 環境搭建可以參照文檔，React項目中View組件需要重新寫過，因為React Native中只支持Flex布局，然後樣式也有限制，剛開始用的時候，難免踩坑，好在React Native的論壇非常的活躍。

本地數據存儲（用來做App本地數據存儲）建議可以用RealM，RealM有專門推出適用於React Native的版本，語法簡潔。感覺從web到native的開發，更多的是觀念上要有一些轉變，比如什麼時候同步服務端的數據到本地數據，那些數據需要同步，還有同步的時間戳等等。建議可以看一些native開發數據方面的文章，全面了解一下。

就這樣學了React你就可以開發Web端和App端了。我愛React

三、vue

最近換了個公司，到了美圖。用了兩天完全了解了vue、vue-router、vuex。終於可以對它進行評論了。

首先，vue確實是一個很好上手的框架，文檔齊全

四、既然用了這些框架，就盡量不要再去導入jQuery這種直接操作dom的庫了.......

回到題主的問題，angualr2 、 react 、 vue學哪個好？

我覺得是看你目前的需求需要。我可以確定的是，如果你完整的學好一個 框架，再想去學兩一個框架，其實是很快。生命不息，學習不止......加油共勉。

---

這個題問得，如果是問「我做某個具體項目，該選那一個」，或者「我打算入門前端，該從那個學起」，倒是正常的問題。但問「學習該選哪一個學」，這就相當於小學生或中學生（無貶義）問：「我精力有限，數學物理化學（反正都是理科）該選哪一門學」。

學習講究的是相互印證，舉一反三，思維激蕩。僅以「學習」這種方式，如果你真能埋頭選一樣，每天投入大量時間學習，最終理解到工業標準大師級，那你回頭去學其他幾樣都是小兒科。但絕大多數人做不到，要麼太枯燥要麼不夠（絕頂）聰明。那效率更高的辦法就是幾個一起學，在某本書，某個框架里難以理解的東西。換本書換個框架，互相比對，沒準就豁然開朗了。

小學時學pascal，指針搞不懂，就同時學C (大量指針）和GWBasic (沒指針）。遞歸搞不懂，就同時學Logo。大一時學delphi用不好面向對象，就同時學C++ (當時靜態面向對象實現的範本）, foxpro （只有介面不能繼承實現的准面向對象）。可惜那時沒互聯網，不知道Java和Javascript，不然應該也一併看了。 工作後自學ruby，感覺lambda會看不會用，就同時學Scheme, Scala, Haskell。比起埋頭只看一樣舒服得多了。

講真，有三個風格各異，殊途同歸，還都是主流的東西擺在你面前，都不用你去挑了，那是福氣。

---

首先你要知道框架這個東西的產生是跟業務邏輯分不開的。

如果你沒有任何項目經驗，學什麼框架都是一樣的，那你抓個鬮就知道要學什麼了。

如果你現在要在工作中用，那你只要比較一下這三個框架分別適合用在什麼樣的業務上就行了。

當然，為了拓寬知識面，你可能需要什麼都學，因為只有這樣才知道每個框架的優缺點，在項目中你就可以取長補短了。

---

各位大神各種分析，感覺可以精簡一下，我給一個簡單的回答：

你需要進行以下幾步：

1、學習：淺嘗輒止的學習，培養自己快速上手的能力，現在環境很好，查找資料很容易，建議國內學習視頻網站，官網api，論壇討論三者結合的看，做到3天左右的時間（晚上3-4個小時學習）可以將官網提到的所有的demo相似的功能實現出來，在這個階段，你要做到，任何交給你的任務，都是能被快速，準確，高效的完成的

2、圍觀：圍觀技術的使用場景，用某項技術在做什麼，為什麼這麼做;圍觀這項技術的發展方向，（比如現在的express和koa）如果團隊小，盡量找被大公司趟過雷的，在這個階段你要做到，任何需求場景，你的技術選擇都是接近最合適的

3、工作：結合你手頭的工作，以最小的代價完成任務，這個過程要考慮幾個因素：開發效率，維護成本，交接難易程度，如果有必要，在這個階段你可以開始review項目的源碼，提高你對技術的認識，同時這個階段完成後，你應該可以完全hold住項目

至於你說的這三者，我個人的建議是根據 工作需要&>&>興趣驅動&>&>周圍人建議 進行選擇

---

反正我三個都學了

還學了avalon meteor

不就是個折騰么.

---

以技術發展為重，都學。

以職業發展為重，如果公司有主推框架，用之，沒有，用react。

---

都學 我最近花時間都擼了一遍

---

1.愛好。

沒性趣再好都是浮雲。討老婆也一樣，喜歡就行，哪來那麼多理由？學通透了，都是神。goto 2;

2.其他因素。

團隊都用啥（招人，成本，歷史遺留，會不會學完就跑等等都是原因）

工資（誰給的錢多。。愛好就是什麼。。其實，這就是市場）goto 1;

題外話：有時間做別的。

react.js, angular.js, vue.js 打架搶蛋糕賺錢，和你有啥關係。。別糾結這個浪費時間。。擲骰子就行。。

有時間泡泡妞，看看電影。過一輩子的，是自己的身體，家庭，老婆孩子，父母和朋友。明天和意外指不定誰先來。

如果明年又來個xxoo.js， ooxx.js 打架。。。然後又糾結了。。

死循環，卒~

---

這幾個框架都用過，個人覺得vue.js比較好。最近用vue2.0寫了一個高仿餓了么的Demo，感興趣的話可以來看看 SimonZhangITer/VueDemo_Sell_Eleme

---

推薦閱讀：