我們為什麼需要 React？

7月13號更新,

其實我想問的不是angular跟react哪個好,哪個不好.

我想問的是,react的代碼相對繁瑣,那麼在繁瑣為代價的前提下為我們解決了哪些痛點?

最近在學習react,

react概念雖然簡單,本身使用這個庫也不複雜.

但是學到後面一點冒出了三個東西:

Flux,Reflux,Redux;

加上這三個東西,我就覺得react一點都不簡單.

因為react學的還不夠深入,所以還沒有意識到很多問題.

但是既然出現了Flux,Reflux,Redux,存在肯定有存在的理由,

那就證明react在大型一點的項目的時候,會存在一些問題.

最近看了一些關於Flux,Reflux,Redux的文章,雖然隱約感覺概念很簡單.

但總是看得雲里霧裡的.

不過有一點是真實存在的 —— 繁瑣.

用這三種模式下寫react感覺相當繁瑣費勁.

但是在angular裡面就相當簡單明了,

一直都說react不能跟angular比較,

因為react只是庫,angular是一套框架,一套完整的解決方案.

但是react加上Flux,Reflux,Redux任意一種,總能跟angular比較一下了吧.

比較的結果就是 react在開發項目的時候,非常的繁瑣.概念也不少.

我感覺學習react曲線比起angular還要陡峭.

都說react有了虛擬dom,解決了性能問題.

但是angular使用了這麼久,也沒見有什麼性能問題.

詬病的臟數據檢查,也沒有表現出明顯的性能問題.

之前angular出現的很多問題,大家都有非常完美的解決.

react的組件在我看來跟angular的指令也沒有什麼特別的優勢.

我們在什麼樣的場景下需要選擇react?

react 確實給我們帶來了很清晰的組件化的思想.

或許也給我們帶來了一些便利.

但是我感覺為了得到一點點好處,增加了開發的繁瑣.

是很不值的.代碼越繁瑣,就越容易出問題.

---

我們需要技術棧提供好用的模塊化方式，可以是Web Component，可以是非Web Component的某種機制，不管什麼庫或者框架，我們需要技術賦予我們完成一個抽象，一次構建，多處復用的能力，並且這個過程不能太麻煩，不能做個很日常的抽象翻半天文檔。

我們需要數據綁定，在各種粒度上真正實現事件驅動，因為這樣我們就不用自己重複手寫本質上並不依賴場景的從視圖到數據從數據到視圖的自動更新，否則我們就得自己操作DOM，優化DOM操作，還要自己維護狀態，一自己維護狀態，就要陷入狀態同步的漩渦，浪費大量時間和精力。

我們需要技術棧隱藏掉平台的微妙差異，寫一段代碼可以真正實現跨平台，而不用我們自己糾結於那些本不該應用開發糾結的事，我們需要持續穩定的跨平台支持，最好的移植就是不用移植，這在商業上有很大的價值。

我們需要庫或者框架好學，好用，從第一天起就能快速開發，而不是不得不經歷幾個月的學習曲線那種，因為大多數團隊的程序員水平都存在梯度，我們不希望因為一個技術棧把初學水平的人擋在門外很久，理想的狀態是技術本身能對招聘工作完全透明，同樣的工期，同樣的項目，隨時找人都可以，招人的時候不用寫得過於具體，只要會JavaScript就能快速上手，我們需要概念負擔盡量少的技術棧，真正理解了Simplicity的技術。

我們希望技術棧有非常好的性能，性能的水平和垂直擴展性都很好，這樣我們就不用項目寫到一半回頭去糾結應用開發團隊很難解決的性能問題，我們需要在快速開發和基礎性能之間平衡得很好的工具，而不是因為要強調某一方面而對另一方面關注太少的那些工具。

我們需要使用的工具有專業的團隊或者社區持續地跟進，最好這些團隊和社區自己就把自己的東西投入生產使用的技術，這樣至少對我們來說風險就有起碼的控制。我們不需要那些心血來潮，永遠不成熟因為永遠沒有專門投入的技術。

我們需要那些普通人喜歡用，也用得好的技術。

React滿足上面的一些方面，不滿足另一些方面，和其他工具一樣。你需要React，是因為兩點

第一，你充分評估了你的項目，理解你要解決的問題是什麼，是快速開發，性能，團隊的ergonomics，多數情況下要解決的問題是多個要素的平衡

第二，你充分評估了React這個棧，理解它是解決你的具體問題的最佳工具，你真的理解了自己的場景中非用React不可的那些事情

如果你覺得React快所以需要，事實是React並沒有那麼快，尤其是大型應用，小型應用里快是不重要的，所有的框架都足夠快。

如果你覺得React開發快所以需要，事實是React並一定是最好用的，尤其是當你考慮了團隊的構成。

如果你覺得React是Facebook開發的所以需要，我的揣測是經歷過一個社區adoption的高峰以後，Facebook未必能解決剩下的那1%的問題。

如果你覺得React Native很火所以需要，這或許是一個理由，但RN也不是唯一選擇，從各方面評估，NativeScript這樣的棧並不比RN壞多少，也許還稍微好一點。如果是大預算的商業開發，RN甚至不應該成為首選。

---

首先題主要區分兩個概念：React 本身和 React 生態圈所推崇的主流應用架構。

React 本身其實還算簡單的。最簡單的理解，一個組件的渲染函數就是一個基於 state 和 props 的純函數，state 是自己的，props 是外面來的，任何東西變了就重新渲染一遍，是不是很簡單？

但是，如果拋開 React 生態圈現在所有的那些東西，只用 React 本身來做個大型應用，你 hold 得住么？我可以打包票，99% 的開發者 hold 不住。因為大型應用會帶來很多規模上的複雜度，比如跨組件通信，多組件共享狀態，多人協作的可維護性，大量嵌套組件的性能問題... 等等。這些東西如何處理，都是靠前人填坑才一步步產生了今天的各種設計模式。Flux/Redux 的繁瑣，本質上是針對大型應用的複雜度所作出的權衡：用繁瑣一些的 API，換長線的可維護性。在規模不夠大的應用里，這些問題並不那麼明顯，那麼這些繁瑣的 API 也就顯得有些過度設計了。

Dan Abramov 自己在推上多次強調過，Redux 的設計是以幾個原則為優先的：要讓狀態的變化可追蹤，可重複，可維護。為了達成這個目的，才會有 reducer, action, action creator, middleware 這些概念。本來一個 callApi(res =&> a.b = res) 可以做到的事情，現在你需要先寫全套然後配上 thunk middleware 才能做到。因此在規模不夠的應用里使用 Redux 肯定會覺得殺雞用牛刀。然而 React 生態圈裡面之前並沒有適合中小規模應用的狀態解決方案，因為 Flux 從一開始就是沖著 Facebook scale 去設計的，並沒有考慮中小規模的應用。最近 MobX 也算是在 React 生態圈裡搞出點小動靜，就是因為它填補了這個空白，然而用 React + MobX 本質上就是一個更繁瑣的 Vue。

如果做個比較的話，Vue 本身不加任何庫就可以很好地滿足中小規模應用的需求，配合 Vuex 可以滿足大規模應用的需求。同時由於 Vue 的依賴追蹤機制，不管 1.0 還是 2.0 都不存在過渡重渲染的性能問題，shouldComponentUpdate / reselect / ImmutableJS 之類的統統不需要。

其實本來沒想提到 Vue 的，只是因為有些人的答案裡面非要拿 Vue 來比較。

回到題主最早的問題，我們需要 React/Redux 么？從可維護性的角度考慮，大型應用確實需要，但這不代表任何規模的應用都得用它，更不代表它就是最好的。如果一個方案能夠用更簡潔的方式滿足你的項目對應規模的可維護性需求，並且讓你用得爽，那就相信你自己的心，不要因為一些宣傳文案看上去很高大上就盲從。

很多 React 傳教士喜歡標榜 React is not easy, but it is simple... 我想說，Life is short, easy is underrated.

總結一下：別人說用得爽，不代表你會用得爽；自己用得爽的才是真的爽。適合自己（或者手頭項目）的才是最好的。

---

既然從 Angular 過來，為什麼不學習下 Vue 。你會從 Vue 中看到 Angular 和 React 的很多影子，在未來的 2.0 版本中，Vue 還加入 Vitural Dom，可以說是把 Angular 和 React 的優點都汲取了。

---

react/vue/angular2我都用過，個人感覺react很多地方還是有過人之處的。

誠然如果只是react而不是react全家桶，確實簡單，但也甚至無法勝任小項目。於是乎出現了redux, react-router來救場。我個人比較喜歡react的地方就是數據決定視圖，很符合函數式的思想（估計大部分react粉就是因為這個原因喜歡上react的）。react生態圈目前可以說是三大框架中最完整的（還有react native來助陣，雖然坑較多，但也快填平了），也是目前唯一經過大型應用考驗的。

react一開始只是一個庫，但是這兩年特別火，不斷有人往上面添磚加瓦，現在已經成了一個比較完整的生態圈了，就目前而言，他不像一個庫，而像一個框架了。

反觀angular，這個完整框架現在也拆分成各種小組件了，我到是覺得這是框架解耦，變成一個一個的庫。angular數據流管理官方推薦的是Rxjs，是函數式和觀察者模式的混合，和react比也不分上下。用於不用完全是個人習慣問題，技術上倒是沒什麼優劣之分。

Vue算是學習曲線比較平緩的框架，國內比較流行，設計也比較符合國人思維。這裡就不過多評價了。

這些告訴我們，目前的三大框架還是比較發展趨同，以後免不了一場惡仗。勝出者是誰我不知道，我也不關心，因為我都會（認真臉）

---

國外現在是React一統世界，不知道知乎上為什麼唱衰的比較多。React已經大量得被各個公司各種產品使用，也就是說React已經不是未來的技術，使用React也不能說很潮了。

關於React的好處，和Angular的比較之類的文章有非常多，大部分是一兩年前寫出來的，現在的文章基本上是React最佳實踐是什麼，React怎麼上手之類。可以看出React到底需不需要，到底好不好，和Angular比較起來如何等等都已經算是有定論了。你不用該不用，但是從React社區出來的對前端巨大的影響是沒法忽視的，React就像是房間里的大象(Elephant in the room)，你不得不面對它，了解它，深入了解過後還選擇別的框架是你的選擇，不過不了解React及其生態的核心概念(組件化，虛擬DOM，單向數據流，附帶es6，webpack等等)會讓你覺得你已經out了。

至於我個人使用的 經驗，剛開始用的時候的確是有很多字疑問的，用Angular我會更快做出來的東西，我為什麼要用React。用久了就能感覺Angular很清晰的劣勢

- Angular的Depency Injection很醜，為了minify還要用array寫兩遍變數名

- Angular的module和es6 module兼容性很不好

- Scope chain只能讓人越用越糊塗。Controller as也沒改善太多

- Provider, Factory, Service其實是一樣的東西

- 目前的最佳實踐是頁面上所有東西都用Directive,強制組件化(那為啥不直接用React?)

- 侵入性太強，需要學很多Angular特有的語法，track by, transclude, $開頭的所有變數，scope, promise. http 都必須使用它提供的

而React的優勢，今年React Europe上Cheng Lou的演講就很好的說出來: Html完全不能滿足我們對於前端app的需求，所以React給了我們全部javascript沒有html的方案，這給了我們可以使用完備的程序語言來構建頁面的能力，同時對於優化則是做到最底層minimum DOM diff。

我覺得程序員需要有一種對一段代碼是否是正統的直覺，比如使用setTimeout(fn, 0)來跳出當前執行感覺是Hacky而不正統，比如arr.constructor === Array 就覺得沒有 Array.isArray()正統。而使用過這麼久React的個人感覺，React中大部分概念是正統的，是rightful的，遠比Angular要多。

最後還是再強調一下React是當下前端是繞不過去的坎，已經不是不妨了解一下的程度，而是不了解要out了。當你深入了解了React，再挑React的毛病，會讓你可信很多(就像Cycle.js作者一樣)

EDIT:

問題更新了，那就更新一下關於React本身和生態吧。

React從發布起幾年來有過幾次變革，基本上React發展的時間和這幾年前端工程化迅猛發展有很高的重合。記得當時是用React.creatClass定義組件，還是用著es5，用著mixin。而es6的發展紅紅火火，萬眾所歸，React也適時得推出es6 class syntax。之後redux帶著函數式的概念一統各類flux，順帶函數式呼聲越來越高，React也推出了functional stateless component。

Build tool方面，記得當初還是grunt的天下，接著gulp取代其位置，和babel browserify一起接管React項目中各種任務(transpile js/css, uglify, sourcemap, concat等等)，之後是React和Redux各大神看中webpack能打包多個文件和hot module reloading的特性全部轉入webpack，webpack也的確給力，打包起來比gulp方便，debug又有webpack-dev-server這個大殺器。

一開始React就是宣傳兩個概念，組件化和virtual dom，這些基本都被說爛了，而個人看法除了這兩點，React最大的貢獻一是一直幫助整個前端進入工程化，標準化的時代(使用virtual dom和jsx轉換的library是可以替換React的)，二是將函數式思想介紹給前端。functional stateless component就是 view=f(state)而redux核心也就是nextState=f(state, action)，也催生了很多函數式的最佳實踐，比如action creator和reducer必須是沒有副作用的pure function，比如使用immutable操作(concat,map替代push,forEach)。

要說現在用React做網站設置繁瑣嗎？當然繁瑣，要設置eslint，babel，webpack，用boilerplate最終還是要了解各個不同的東西是幹嘛的，不過把這些歸罪React也不是太恰當，畢竟是整個前端生態圈都進化了。用Angular 2或者Ember你還是得用到這些。React的繁瑣基本都在redux上，得creatStore還得加入middleware還得用connect()連接到store，而帶來的高階組建的概念不好懂也不容易用。

React有它自己的缺點，畢竟我們上哪找完美的東西呢？Boilerplate過多，setState是非同步的，context api很坑爹，server side reder各種坑(設置hmr，哪些call在伺服器做，哪些只能在瀏覽器運行等等)，animation到現在都沒什麼太好的方案。

不過React值得用嗎？當然值得，它給你組件化頁面，入門函數式，清晰的單向數據流(dispatch(action)-&>reducer-&>render)，深入了還有高階組件的composability，能發現selector和reducer其實也是composable的，順帶著各個工具的使用(eslint, babel, webpack)，不小心還能入Elm和Clojurescript的坑。

還有一個經常被提起的好處是React redux做的網站，重構非常方便，在需求永遠不固定的世界裡也是一大優勢。

所以，這麼多大公司轉用React也許不是因為他們都是傻子，也許React確確實實帶來了好處。

---

這屆觀眾的問題就在於，用框架只用新的，不用對的。

用不用React得看場景，比如天貓，淘寶這種電商類的你所有頁面都上React試一試？這種智商問題就在於，完全不care用戶，只要自己爽就行，如果是創業公司，我敢說絕對倒閉.

---

我給別人推銷React的時候從來不提「性能」二字。因為React的魅力真正在於組件化開發中各種引領前端潮流的思想，以及在此思想之上帶來的大型應用中組件可維護性的提升。

說他繁瑣不假，這只是一道門檻，過了這道坎，你更多的感受是自然。

再來說說關於基於模板語言的框架。

模板語言是前端技術發展的中間產物，表現能力差，可維護性和擴展性都不夠好，早晚有一天被淘汰。

至於未來是不是一定就是React，不一定。不過目前來說React做的比基於模板語言的框架都好。

14年剛接觸Ractive（和早期的Vue很像的一個MVVM框架）的時候，確實爽的飛起（那個時候Vue才剛剛起步）。

早期業務模型和組件交互很簡單，也沒有產品經理的吹毛求疵，完全開發者自己主導。

雖然Ractive的生態基本為0，但大部分功能自己實現起來開發效率確實杠杠滴。

一年過後，一些常見的組件比如日曆控制項、表格分頁、排序、各種圖表面板都開發的差不多了，日常的需求基本上也能很快迭代完成。

不過這個時候創業公司也慢慢變大了、走向正軌了，開始有了產品經理和設計師的強勢介入。

隨之而來的是各種UI和交互的「精心設計」，組件也越來越複雜了。

最開始我覺得問題不大，我們有業界先進的MVVM，難不倒的。但是隨著產品經理和設計師腦洞進一步擴大，我發現我真的過於樂觀了。

就拿Ractive來說，各種雙向綁定的BUG，很多時候不得不各種hack（國外有人說雙向綁定帶來的複雜性遠大於便利性我真的是深表贊同）；

其次就是組件開發能力太渣，由於近半年React用的太爽以致於我已經忘掉它為什麼渣了（大概就是擴展性，維護，調試）。

為什麼我覺得基於模板語言的框架沒有未來？

主要原因是一旦你使用了模板，必然與JS割裂開來，為什麼割裂？因為模板語言的設計者就是這麼乾的，如果你質疑他們，他們有很多理由來反駁你。

雖然模板語言在有些情況確實能提供一些便利性（最常見的比如列表輸出），但是它的局限性更大。比如使用純粹的JS你坐享各種變數和作用域，使用起來再自然不過，到了模板語言那裡卻是各種蛋疼（因為模板語言的設計者認為你壓根就不應該在這裡做）。但是又有很多用戶需求點卻又不得不妥協，導致模板語言開發者不得不擴展模板功能，隨之而來引入更多稀奇古怪的語法，增大模板的學習成本和BUG出現的頻率。這種局限性是非常致命的，導致模板根本無法方便擴展提供更多功能，也註定了在模板語言這個層面，框架很難有大的突破和創新。

---

在此聲明一下，只是想通過技術角度去評價框架，並無意去指責或者去嘲諷其它框架，如某些言論表達得不恰當，請私我，我可刪除。對於無意義的漫罵或指責，表示不接受也不回復。

關於React的問題，我有幾點要說：

1、React確實存在組件嵌套的性能問題，但是可以通過Redux去解耦以達到目的

2、對於引入immutable / reselect 對於大部分並不是必需品，組件粒度越細，state使用得越少，需要引入shouldComponentUpdate的情況越少，其實在項目中真正有用到它們的有多少呢？

3、React的中大型項目上的應用並不是太大的問題，國內有Ant.design已經在大量的螞蟻金融平台和或各類內部平台上使用，儘管Vue也有，但只是實驗版本，也並沒有再去升級。 在國外：faceBook算大型應用嗎？它本身已經就應用了React 16 Alpha 版本，以身試坑，這樣算得上 React 在大型應用上有問題嗎？

4、React是有門檻的，確實沒有Mv**那麼快讓人容易接受，需要有一定的JS基礎和開發經驗。

5、對於理解Redux，有些人需要些更多的時間去理解，有些人卻能夠在短時間快速掌握，同樣是在中小型應用中，確實是有些繁瑣，可是我們同樣可以通過Redux-Actions去簡化這些繁瑣。最簡的Redux-actions寫法如下：

Action:

let increment = createAction("INCREMENT", amount =&> amount);


Reducer

const reducer = handleActions({
[increment]: (state, action) =&> ({
counter: state.counter + action.payload
})
}, { counter: 0 });


1、action.playload = amount

2、state.counter 來自於 store.counter

註： 在中小型應用中，這麼寫法，算很複雜嗎？難以理解嗎？推薦您往下讀讀我對Redux的理解。

再一次題外話：很認可Vue本身帶來高效率的開發和很低的學習曲線，並認可作者的努力，也覺得Vue未來能夠給大家帶來更多優秀的特性，但是我們不能夠忽略Vue及Mvvm本身存在的問題，同時也是希望我的分享能夠給大家帶來個人對框架的體驗。

我是從0.12版本開始使用Vue的，大概使用7個月+吧。開發的項目本身更多的是通過自定義控制項，讓用戶更快的構建自己的遊戲管理，已經接入了數十款遊戲，遊戲本身給公司帶來的收入達到數億計。我不敢妄自菲薄稱該項目是大型項目，僅僅只是一個中小型級別的項目，我來說說在這項目中使用Vue帶給我的體驗。

1、Vue確實簡單，文檔非常清晰親民，可是API數量太多，數次遇到的問題都是因為對API的不熟悉，同時概念太多，儘管完成了項目，但是很多地方邏輯處理得不是很讓人舒服

2、翻開代碼，我依然看到我不成熟地使用inherit特性所導致繼承組件帶來更多無意義的變數，常常因為一個變數的變化，常常影響子組件的屬性，直到API官網出現了最佳實踐，方知自己錯誤的實踐。

3、滿屏的的v-mode / $watch / $on / $emit / $dispatch / $set / this.var 讓我們調試問題變得更複雜，因為我不知道究竟斷點該斷在哪個位置，還是在視圖才能夠更快的找出問題，因為我一開始覺得使用它們是更輕鬆、更舒服的方式。我相信作者也敏銳的發現了這個問題，把$dispatch在2.0給移除掉了。

4、更為神奇的是，我在文本框以及它的父組件使用v-model時，發現輸入中文，發現中英文同時出現文本框里，我發現這個問題是在於我使用0.12.6 之後的版本才會出現，而0.12.6本身並不會有這樣的問題，當然最後我使用了 v-on keyup 來解決了。我相信是我的使用姿勢不太正確。

5、Vue.Compnent / Vue.Extend / ViewModel 它們的 options 重疊相同的部分太多，在項目中每個人都有自己喜歡使用的方式，假如不合理使用，可能導致，各種data不合理的出現在不同的位置。

Vue確實是一個優秀的新秀，使用它，你並不需要擔心有比較嚴重的bug或者性能問題，但是你仍然要擔心的是在大量的刪改API情況下，我如何從0.12遷移到1.x，2.0， 我有想過，我被1.x那些優異的API所感到新奇和驚喜，但是大量地使用 inherit 導致更新起來邏輯調整更困難了。

相信作者對於JSX，還是有一定相法的，不然也不會去在2.0引入JSX。而恰恰地，存在一個問題，框架本身帶來的可選項太多，我們如何快速的識別它們帶來的副作用，讓我們如何提供更優雅的方式去使用框架。那麼同樣的問題也存在了，究竟我們是選擇JSX 還是 template呢？

而Vue 2.0刪改了哪些API呢？我很無聊地去數了下，大概有30+的API，我例舉下些可能大家可能曾經會用到的部分API：

Vue：（刪除）

Vue.elementDirective / Vue.partial / options.replace /

生命周期：（更名）

init =&> beforeCreate

ready =&> mounted ?

compiled =&> mounted?

options（刪除）

partial / elementDirectives / events

Dom（刪除）

vm. $els / vm.$set / vm.$get / vm.$delete / vm.$dispatch / vm.$boradcast

vm.$appendTo / vm.$before / vm.$after / vm.$remove

Directive（刪除）

v-ref / v-el

我們相信作者刪除它們是為了簡化API的負擔，可是這些API，是否又能夠輕鬆的從項目中遷移呢？特別是DOM，相信大家自有定論。

同時React也存在，使用它周圍哪些庫更輕鬆更簡便更合理地開發呢？可幸好，它們是可選項，而 Redux也僅有2K代碼量，想要重新實現它帶來的思想是一件很輕鬆的事。

使用React，讓我感受到組件本身帶來強內聚，搭積木式的組裝體驗，通過 render 函數更直觀的看到 DOM 結構，這也是為什麼我使用 React 的原因。

我並不排斥任何新框架，新事物，對於任何框架我很欣賞也很欽佩框架作者的技術能力，但是我仍然不想忽視框架本身存在的問題，因為沒有完美的框架，只有適合的應用場景，選擇自己更適合的，不是嗎？

====================================

題主亂帶節奏，帶偏一幫老司機飈車飈錯了方向，我就我有限的經驗聊聊React解決什麼痛點，以及我們為什麼需要它吧。

在此之前，我先做個聲明：

框架都是為了提供某類開發場景而生的，性能只是加分項，再厲害的框架也牛不過原生擼碼！

現在主流的框架（主要以React/Vue/Angular為背景）都主要以有限數據狀態機來解決複雜的交互應用場景、編寫可控可復用的代碼以及開發效率問題。而它們所謂的繁瑣是相對於應用場景和人的。

題主說到React繁瑣，指的是他並沒有理解Flux/ReFlux/Redux為什麼要擼那麼多代碼來實現原來僅僅只需要$.ajax就可以實現的數據交換以及組件間通訊問題。

其實我恰恰認為它們（Flux/ReFlux/Redux）並沒有 優雅地解決數據交換以及組件間通訊（不喜勿噴），在我的項目中我已經拒絕再去使用它們，那樣React變得更輕量了？

可我們依然要面臨組件間通訊繁瑣的問題：

1、通過父組件通過給子組件傳遞函數到Props，重繪父組件達到更新兄弟或兄弟的子孫組件達到目的。但是，重繪父組件會導致其所有無需更新子組件重繪，同時可能導致被動更新的子組件某些與props有關聯的state 被更新（state丟失）。只能通過ShouldComponentUpdate 者componentWillReceiveProps去解決此類問題。對於孫子以下的組件更新更加繁瑣及麻煩。

2、通過一個中轉容器去解決跨組件通訊問題（例如EventEmit/Redux等），但EventEmit卻沒有更好地解決數據與視圖分離，以及Event本身帶來的閉包、隱含邏輯依賴關係和時序問題（通俗的說，項目大了，不同對象的不同的事件名稱、參數和調用關係變得很亂）需要有一個很合理的解決方案。

而我們，只不過想把某些個數據發送到指定的組件里執行。而我認為吸取Event/Redux等的經驗。我們可以這麼做：

1、提供一個數據容器，所有數據都直接發送到該容器，這樣我們可以輕鬆做到Redux的可預測和可回溯。

2、關聯組件所需的數據到該數據容器。

3、約束數據發送時，接收組件的父級及子級不允許被更新（很多人在做組件設計時，父組件接收數據A的KEY1,KEY2，而自己接收數據A的KEY2和KEY3，這樣是錯誤的設計，應該把接收數據A的KEY1,KEY2的內容拆成一個子組件接收）

等等，這不是和Redux差不多嗎？

NO, NO, NO, NO，請耐心聽我說完。

差異在於：

1、我們只發送數據，不需要定義ActionType等等

dispatch({ key1, key2})

dispatch({ key1, key2}, reducer)

註：reducer是可選項。

這樣我們便可以很輕鬆地，將它們封裝起來

dispatchUser = paramter =&> {

// promise.all(login, xx).then(..)

// fetch(json).then(..)

// dispatch(json, state =&> object.assign({}, state, json))

dispatch(json)

}

2、配置接收數據的組件

connect( state =&> ({ key1, key2 })(componentA)

class componentA {

getStore(state) {

this.setState( { key1: state.key })

}

}

註：假如你想默認直接更新，稍微包裝一下就實現自動setState。

具體代碼我最近還在開擼了，擼好了，再告訴大家。

當然使用Redux，可以藉助Redux-Actions去簡化我們的實現。具體可看：GitHub - acdlite/redux-actions: Flux Standard Action utilities for Redux.

選擇React：

1、我們可以使用最簡單的JSX方式去封裝我們的組件，我們只需要關注我們需要接收什麼數據，以及展現什麼內容， & 多麼直觀啊

2、只要熟練JS，就能夠很輕鬆實現絕大多數模板語法的內容

3、因為API足夠少，我們有更靈活的發揮空間

4、開發環境下，足夠豐富的錯誤提醒

5、React版本迭代遷移，工作量並不大，有遷移提醒，API刪改少量且遷移成本低

6、不會引入大量的概念到React庫里，保持純凈，其它周邊庫都是可選項。

也有人質疑JSX，寫起來不是那麼的好看和直觀，其實寫多了，你會逐步體驗到它帶來的好處。例如分支判斷可以拆個無狀態組件等等。

未來可能會有更多優秀的框架，但目前，選擇React仍舊是一個不錯的選擇，不排斥Vue，但是 API 不斷的刪改，引入的概念這麼多，如何根據這些概念給出一個最佳實踐到項目中到團隊中呢？這又是一個新的問題

題外話：

假如您只是一個營銷類的推廣頁面，僅僅只有輪播、幾個文本框的表單的極淺交互，我還是推薦大夥使用原生 / zepto / jQuery之流。

假如您很在意體積，計較網路環境（2G/3G）等，可以使用伺服器端渲染或者無阻塞UI（即添加佔位符），使用帶有GZIP的CDN，React各類庫絕對能夠在100K以內，假如超過，建議您使用按需載入。我相信您的伺服器應該會添加有304/ETAG之類的緩存。

對於中大型項目，React確實是優良之選，當然也可以嘗試Vue去迭代中小型項目。

=====================================================================

做為一個在從Angular到Vue， 最後選擇React，並有實際項目經驗的人告訴你。React我們需要它。

框架都只是為了開發效率和良好地組織項目代碼，並不完全是為性能而生！

框架都只是為了開發效率和良好地組織項目代碼，並不完全是為性能而生！

框架都只是為了開發效率和良好地組織項目代碼，並不完全是為性能而生！

對於只會Copy/Paste的人，很好奇，他如何很好的維護那糞池？

Angular1.x 那些醜陋的特性，其實可以用ES6 或者 Typescript 進行二次語法包裝，一樣能夠寫得很漂亮的，隱藏很多讓人無奈的細節。具體可以看：GitHub - ulfryk/angular-typescript: TypeScript 1.7 annotations (decorators) for AngularJS 1.x

這些僅僅只是有限的包裝，你可能還需要包裝更多更多的特性，不過這樣真的好嗎？

Angular 2.0.0 rc.4 （目前確認的最新版本） 已經醞釀了一年多了，語法幾乎完全脫離了1.x版本。它似乎要把目前主流框架和特性都要集合到一塊，如vdom、rxjs、typescript等等，源碼模塊引入了rollup去打包框架代碼，業務代碼依然是webpack。 然後我們默默地打開一下它的API文檔，數百個API指令（請容許我誇張地虛報了個數字），如此大而全的框架，讓人唏噓不已。依然延續了1.x的繁瑣複雜的語法，當然我們不能否認它們的一鍋端設計，只不過適用的場景實在是有局限性，Ionic2這個Hybird端的老搭舊已經率先同步了。

儘管Typescript強健了我的代碼，提升了我的開發效率；

儘管Rx革新了我的數據流，完美地封裝我代碼中那些不完美的代碼邏輯

但是... 我依然沒有辦法再去學習這幾百個API。

Vue相當不錯，從一開始是一個簡化版的Angular1.x，一年內從0.x 一直 飈升到 2.x ，作者一人撐起了80%+的生態，幾乎覆蓋現在主流的特性和小庫。性能一直號稱業界姣姣者。

等等，我們好像忽略了什麼？

Vue 1.x 到 2.x 開始閹割大量API和模板語法。讓一直追隨他的小粉絲的我，開始懵筆了，我的Vue項目已經開始準備1.3，1.4的功能開發了，而我卻只能使用0.x 看著別人快樂地用著1.x， 2.x 擼啊擼。

看著作者愉快地將某些個模板、某些個生命周期、某些個事件等等語法一而三，再而三地不斷地改啊改啊的，還能愉快地跟得上這股風么？

與此同時Vue開始在2.x引入JSX的語法， 開始有點走Angular2小邪路，對於某些新人來說，我開心地時候想用JSX，不開心地時候，我喜歡用Template語法。這樣的可選項是否合適呢

不得不說，Vue的生態、文檔、性能等等各方面都都是業界的姣姣者，只可惜Vue只適合中小型項目的開發，已經開發夠快，夠穩定，概念夠新，適合快速迭代的項目，但是對於中大型項目需要的是穩定....

修正一下，有人說vue2.x哪裡支持JSX，先晒晒作者微博上的圖（侵刪）：

看完上圖是不是感覺和React相似度已經60%+了？當然還有*.vue/vue.component，是否作者是考慮讓用戶安穩的過渡到JSX？還是維護JSX和Template呢？那麼最佳實踐是什麼呢？

React 是唯一一個讓我真正體驗到編寫代碼快感和舒適感。（儘管在此之前我很排斥JSX）

簡約的語法，輕量的API，組織代碼時的穩健，時時刻刻讓我爽到溜起....

怎麼簡約輕量？可以看這裡多個主流框架的語法對比：Front-end Hyperpolyglot

穩定的API，每次升級都是在強化和優化，相當少少少少量的API更新，即將廢棄的語法，都會有警告提示，讓我們更快的升級架構。

flux/reflux/redux 不僅僅只能用在React，也能用在Vue/Angular等等框架，僅僅只是一個數據流思想，您選擇性地使用。

其實概念很清晰，舉個Apple雲很簡單的例子來形容Redux：

我們的設備（Iphone/Ipad/Mac）的照片、文檔等信息，都發送到雲端。而我們關聯雲端的設備，當雲端有數據更新，就會自動更新到有關聯的設備或應用里。

而我們所說的Action 就是我們點擊數據發送雲端的指令；

而我們所說的Reducer就是介面，我們需要上傳照片和文檔，都需要轉化到 成雲端可以接收的數據格式。比如圖片，需要轉成二進位等等。

而雲端就是我們所說的Store，存儲了數據，很自然的，我們可以在雲端查看數據上傳歷史，還原某一條數據歷史等等，當然更多可以想像的功能，都可以在雲端實現。

而我們需要實現React-Redux / Vue-Redux / Angular-Reudx 等等給到給到各個設備接收數據。

例如React的Connect，代碼連接到雲端接收數據並更新到組件。

React/Redux並不是沒有坑：

1、setState 大量數據時（如700多條的列表），會有點點卡頓，當然我們可以通過優化得到解決

2、父組件更新某個子組件數據時，需要父組件重新組織，會導致其它子組件重新組裝，雖然有vdom，但是這樣顯得不那麼人性化。而且某個子組件內部有某些個state需要保持時，會丟失。需要shouldComponentUpdate..，當然你可以把組件的數據state=》子組件的props設計得更淺一些，至多2-3層，使用 redux，只connect具體需要更新數據的組件，粒度越細越好，保證單個state只更新到一個組件，這樣還能帶來易組裝的好處。當然粒度越細，自然代碼量也上來了，你也可以採用 stateless（無狀態）組件去簡化代碼。各中取捨，取決於您的設計。

3、React-Redux經常在更新時，會產生過渡使用的問題，比如說父組件和子組件都connect，結果會導致第2點所說的狀態丟失和重複render問題，還會有數據穿透的問題，因為connect只比較一層state。這時引入immutable能夠帶來較好的效果，不過個人認為完全沒有這必要。已經有大量大神使用Event的方式去解決此類問題。而我，正在考慮擼個類似於Redux的方案。

總得來說，你需要React，它並不複雜，而是你聽到的雜訊太多。

對於大型項目，推薦 Webpac 2 來構建業務代碼， Rollup 來打包你的小輪子。使用Rx優化你的數據流。Typescript強健你的代碼，提升你的開發效率（頭一周可能會有些痛苦）。但在此之後的收益是非常高的

對於中小型項目，推薦React/Redux/React-Router來構建你的代碼

不要擔心體積，因為CDN都有GZIP，能夠壓到原體積最高22%比例。

不要擔心打包慢，因為通過優化 webpack，開發環境全量打包能快到 5秒， 生產環境能快到12秒。（vendor 5m 業務代碼2m多）

不要擔心雜訊多，正因為如此，你的提升才會變得更快。

不要擔心性能問題，因為90%+的場景下，你並不需要考慮性能問題。

不要開發效率問題，前人種樹，後人乘涼的感受，會讓你更舒適。

不要說React複雜，因為比起Angular、Vue要簡單些。只不過沒有更好的最佳實踐和文檔，所以你迷失了。

React 有 Flux/Reflux /Redux ，你只需要選擇 Redux，Vue也同樣有Vuex

React 需要 webpack / es6 等， Vue也同樣需要webpack / es6，只是有它有 Vue-cli架手腳，但是React也有各種boilerplate。

比如：GitHub - mxstbr/react-boilerplate: A highly scalable, offline-first foundation with the best developer experience and a focus on performance and best practices.

再比如最新的 webpack 2 / React hot Loader 3 boilerplate: GitHub - ctrlplusb/react-universally: An ultra low dependency node v6 universal react boilerplate with an amazing dev experience.

請Vue/Angular粉不要罵我，我就照我的經歷說，有什麼說得不對，還望糾正。

---

React 或許不方便書寫，但一定方便測試。

React 組件渲染是個函數，state 是其內部狀態，props 是其參數。然後通過輸入輸出就能測試組件的渲染，通過 simulate 觸發事件，就能測試組件的內部狀態變化，從而全面的測試某個組件。市面上還有各種基於 React 的測試框架可以幫助我們很方便的實現這些測試。在這之前，測試 UI 是很麻煩的。

另外，Redux 也方便測試，都是函數，通過輸入輸出就能測試其中大部分邏輯。

在一個需要長期維護的的大型的項目里，這些測試用例就可以降低出現問題的可能，同時節約發現問題和解決問題的成本，還可以降低重構的風險。

而現實中的大多數項目，都是要求快速出貨，怎麼快怎麼來，死了這個就弄下一個，出現線上 Bug 就直接扣工資，用 React 還寫測試的，不能按時出貨就統統加班去吧。所以，我們根本不需要 React。(手動斜眼)

---

我們需要的不是react，而是一個web component＋state machine，前者讓組件化成為可能，後者讓原本的dom操作變成數據操作，維護數據的工作肯定比手動維護dom要來得輕鬆。react自身定位為一個view庫而不是框架，以此來專註於前面提到的兩個部分，應該說，實現這兩個部分並且做好，也不是一件容易的事，從react經歷了許許多多個版本才正式發布了react15，可以看出確實有諸多考量和變故，引入vdom解決了一些性能問題，但是還不夠，這會兒又在醞釀fiber，所以說專註一個view也不是一件容易事。

所以，集中注意力去做好一件「小」事情，比較有成效，特別是棘手的事情。

其他的，像redux專註於狀態管理，這是整個應用的架構層面，當然也不會是花點時間就能做好的，所以它不會被籠統地實現並集成，交給其他專註的團隊做。router同理。

事實上，你做一個應用很多時候用不上redux，vue的文檔也提到過，其實如果只是簡單的需求，一個event bus就能夠滿足了，你也許都用不上vuex，這道理放在這裡也是一樣。

怎麼說呢，我個人比較喜歡像拼裝高達一樣去構建一個項目，所以大而全的框架可能我不太喜歡，而且把零件拆小了，出了問題容易求醫，redux的問題就找redux的文檔，router有問題就找router的文檔。

當然，框架的好處也是很明顯的，一個是啥都替你想好了啥都不缺，一個是風格比較統一，不會像redux跟react那樣，銜接都那麼不自然。

如果嫌react系麻煩，用vue系也挺方便的。

反過來想，簡單的東西實現複雜的功能，當然是一個麻煩的過程，但是它簡單到足夠可靠所以還是值得的；而複雜的東西實現一個複雜的功能，也許很簡單，但是它必須相當可靠，不然的話就是災難，這個要求就很高了，而且對使用者的要求也高。

所以。。。

跑題了，還是繼續「為什麼需要react」，作為現代化的構建方式，component是要的，state也是要的，這些都是被證明了的切實可行的功能，當然以後也可能被推翻～但是就目前來看，主流的框架都支持這兩項功能。

---

用React這種組件化的模式敲代碼讓我有一種類似於搭積木一樣的創造快感，每一個組件都像是一組搭好的積木，你非常清楚自己做出了什麼東西，它長什麼樣，它有什麼用。它對於你來說就是一種獨立的存在，但同時，這一組組搭好的組件又可以拼湊成另一個更大的東西，就這樣搭搭搭搭。這個敲代碼的過程讓我覺得非常爽，很符合人腦創造的過程，或者更準確的說，可能更符合現實中人創造東西的過程，很直觀，出了問題也很容易定位。每寫一個組件，我的腦中彷彿就有了一個形狀，或者說一個模子，存放在一個倉庫中。每次需要的時候，把這個模子拿出來克隆一份，只要加上不同的參數，它立馬就變成你想要的樣子，爽到爆炸！如果你要它在不同時刻表現不同的狀態，也只要操作state數據。

其實，每一個模子的基本結構都定義在jsx和initialState里，這是所有克隆共有的部分，是統一的、抽象的，但卻因jsx的語法讓它顯得非常直觀。而各個克隆體區別的部分和動態的部分又是通過簡單的操作props和state這兩個數據結構來實現的，改變一個數值就可以讓你的組件變成另一種樣子，避免了原先操作DOM的繁瑣和散亂的事件綁定。

以上說的是我從無框架轉到React的感受，如果題主要的答案是React和其他框架的對比，那抱歉跑題了。

另外，所有工具都有它適合與不適合的應用場景，如果你把React用在頁面組件不怎麼重複的項目、把Flux用在不怎麼需要處理數據的項目，那就是畫蛇添足了。

---

前面有個很讓我認同的演講, 思考的是人們怎麼編程: 先為對應的問題建立一個模型, 然後用代碼設計出一套 DSL, 再將代碼進行運算以解決問題.

那麼前端 UI 的更新當然是 MVC 或者 MV*, 也就是用戶操作增量更新 Model, Model 更新怎樣同步到 View.

比如 MVVM, 也就是 Angular 跟 Vue 採用的模式, 常說的雙向綁定, 就是故意設計一些結構, 在 View 上操作時比如點擊一個節點, 執行一個表達式更新一個位置, 雙向綁定意味著界面和數據需要盡量做到一一對應, 不然的話, 從 View 操作的位置查找 Model 的更新的位置會有些麻煩(當然也不是沒辦法解決, 只是說這不是雙向綁定為了解決的問題):

有了大體的模型, 然後就是做具體的實現, 後面還有填各種模型不適合解決的坑.

比如說 MVVM 前面那個 Object.observe 的事情, 後來總算據說因為性能方面問題不了了之了. 但回頭看, 為了找到 Model 布局更新的位置, 各種方案也算辛苦了. 這樣解決了 Model -&> View 的問題, 在 View 到 Model 也是類似的情況, 所有賦值操作被代理了, 以便觸發 View 的操作.

其實在我這種 FP 死黨的眼裡簡直是不可思議, 本來還算簡單的對象, 全部模擬 Atom 類型(腦補一個 Papi醬表情).

Flux 的套路呢稍有不同, 不是綁定了, View 更新會映射到一個 Action,至於 Action 怎麼更新 Model, 自己寫, 挺麻煩的, 不過這樣的話其實就不用受到 ViewModel 跟 Model 之間對應關係的限制了. React 其實吸收了後端開發和函數式編程很多套路. 特別是函數式編程不可變數據. 至於 Redux, 在吸收了 Elm 的優點以後繼續把概念往極端上推, 同時努力跟 ES6 大環境配合.

坑也不少, 首先 DOM Diff 就是為了適應方案而做的, 既然 DOM 是聲明式的 DSL, 更新 DOM 的操作總要寫, 於是通過 DOM Diff 生成出來. 整套方案其實開銷不小, 於是從 FP 社區學了 Immutable 過來, 後面就是讓很多人覺得眼花繚亂到無語的一大串東西.

其實看兩個方案, JavaScript 和 DOM 兩者都是被各種折騰的. MVVM 通過將數據變成 Observable 來變相實現 Reactive Programming, 也就是多份數據之間按照數據流自動同步, js 原生對象簡直弱雞, 乾脆整個 hack 掉, 同時 HTML 也 Hack 成強大的 DSL 系統. 在 React 這邊也差不多, DOM 需要做 Diff, 也需要依賴 Immutable, 乾脆就是 JSX 上來. 對數據類型也不爽, 於是用整個 immutable 模塊替換掉基礎類型. 所以兩個方案其實都把 js 那個了一遍, 建立自己的一整套 DSL.

MVVM 的坑我就不說了, 反正我不喜歡, 我也不會 Java 各種設計模式.

React 這邊的問題也不小, 如果你熟悉點 FP 主流的語言, 一套 FP 的實現長成 React 社區這幅樣子也真夠累的了. 一切皆是表達式嗎? js 設計的時候就不是. 不可變數據嗎? 不是, 一般都可以改的. 結構復用方案內存優化嗎? 沒有, freeze 做不了, 只能自己做. 有隔離副作用的習慣嗎? 整個語言遍布副作用. 非同步抽象呢? 還在制定標準呢.

結果呢, React 得到的就是一個不上不下的方案, 一方面要用到艱澀的知識點去做高級的優化, 一方面要兼顧 JavaScript 巨大的生態. 跟著其他的事情層出不窮, 可變數據和不可變數據混在一起用怎麼樣? Component state 和 Closure variable 混合使用怎麼樣? 在函數式語言當中傾向於在語言層面增加限制, 避免大量出現 anti-pattern 影響全局, 但是 React 很難, 你教人寫 JavaScript 還不讓人隨便寫賦值, 哪有這樣的道理?! 然後 React 只能延續這種混搭風了.

你可以找基於 FP 語言實現的 Flux 的套路, 對比一下 React 混搭的寫法.

Elm https://github.com/evancz/elm-todomvc/blob/master/Todo.elm

Respo https://github.com/respo-mvc/respo-spa-example

回到原來的問題, 為什麼需要 React, 為什麼 React 顯得那麼越來越奇葩. 我認為 React 背後的架構方案足夠清晰也經得起時間考驗, 這很重要. 為什麼 React 越來越奇葩, 因為是混搭風.

---

前端框架我最早用的是ng1，後來也用過vue,再後來就是react了。

要說這三者最大的不同就是react的思路比較清晰(當然也有可能是我沒把ng和vue學好)，一個半年前的react項目 我前幾天拾起來的時候仍然可以無縫的繼續開發。在做其他端的開發時，我一般直接上RXxxx+各種bus，並分理出一些state進行反射調用。所以react+flux的思路很合我的口味。

第二個好處就是react只是個view庫(對，我認為它是個js庫)，所以網路請求，動畫等都可以自己隨便來，和舊的jQ組件在一塊用也不會有很大問題。

第三，react-router太好用了，雖然只是對history API的一層封裝。

總之，react學習曲線非常平滑，使用的過程中每天都在一點點進步，也不會遇到很無解的問題(至少目前我沒有)，而且相對於ng，我認為react很易於後端程序員甚至所有人上手，也適合對老的jQ項目的平穩重構。

ps:我不是專業的前端，文中若有紕漏，歡迎指正。

---

因為React之前前端生態都是逗比。

所以叫它瀏覽器里的JVM也不為過，簡單、穩定、生態豐富。

React之後真正建立起了前端的生態系統：

企業級開發喊了好多年的CQRS / ES都沒幾個人敢用，Flex / Redux作為類似的架構已經滿大街都是。

Node讓非同步編程，基於事件編程成為主流，React讓更難普及的函數式編程，響應式編程成為主流，React是打破OO統治地位歷史的重要一環。

Steve Yegge這些大牛喊了好多年JavaScript不是玩具，Douglas Crockford說JavaScript很像Lisp，根本沒人信。React之後前端開發逼格完爆其他主流開發領域。

React興起的同時正好是ES6開始普及的時候，它徹底主導了前端開發，讓模塊化JavaScript加各種打包方案成為絕對主流，徹底幹掉了舊的html + jQuery工作流。

DDD裡面最後提到的各種高級柔性設計，比如聲明式設計，無副作用設計，分形結構等等這些容易玩脫，但受益無窮的設計模式，你都能在React看到教科書級的使用。

組件非常類似JavaScript本身的Lambda，加了尖括弧就算傳參執行的巧妙設計，還有Props這種萬能參數的設計等等……體現了Facebook內很多OCaml高手的風格。

現在每天刷新無數的React仿照者和競爭者就說明了一切。

但React為什麼這麼叼呢？

可能是前端比較簡單，業務都比較單純，但是工作量也不算小，以前重寫前端的幾率也比較高，一般也沒有持久化和性能壓力。導致人們容易更輕鬆，更肆無忌憚地面對這些工作。

前端也是各種編程場景交匯的地方……不同於後端HTTP Service無狀態的一次對話，前端的展示在時間上是連續的；在請求上是非同步的；處理業務的同時也要對付UI這種不好抽象的東西。業務不難，但是各種領域都有些挑戰，因此前端更容易在庫和語言上更近一步，而不是架構上——你可以看見前端工程師特別喜歡討論編程語言和框架，這比較偏向程序員本身的需求；而後端工程師則更傾向架構師的需求，更喜歡討論架構。

沒有後端部署，架構，遷移，安全等等這些沉重包袱的阻礙，用簡單地代碼能實現某些模式，這時候前端才真正開始思考語言和庫的設計，走向編程領域更核心，更深的層面，而不是架構師受制於各種部門政治，受制於各種現實因素，束手束腳地考慮架構，然後交給程序員寫代碼。

其實React只是選擇了好的時機和好的策略，讓這種現象最大程度地爆發出來。

---

我覺得Angular是一整套的解決方案了，你必須按照它的規則來。而React和Vue相對就輕量多了，尤其是Vue，主要專註在View層，而且可以跟你現有的框架一起使用，你可以選擇只用Vue的雙向綁定來減輕你的業務邏輯，也可以把Vue用的很深入，來開發大型、複雜、復用的項目。Vue和React都是有全家桶的，比如Vue：vue+vue-router+vuex+webpack來開發SPA。

---

因為虛擬DOM性能比原生高啊。(笑

曾經質疑這個被緊跟潮流的同事鄙視了許久。於是我就明白了ng1最大的問題不是性能而是逼格了。

---

不說別的，光module就夠把angular扔了

---

討論這個首先要假設 1 個條件：不拿最後項目體積說事。

好吧，接下來直接表達立場：

（1）小型項目：不討論了，隨你，反正都是小型項目，可選方案如下：

－jQuery 或者 zepto 按照模式構建代碼，比如： MVC、MVP

就如 MVVM 一樣，就是一個代碼的構建模式，所以不用太糾結，用什麼都能實現。

優點：從目前狀況來看，上手成本基本是 0 吧，不過你如果基本模式都不清楚～那就不說了。代碼基本無黑盒，全透明（jQuery 基礎庫就不用擔心了，小底層），所以出問題怎麼都能排除到。生態圈強大，各路插件齊全。

缺點：需要手動操作 DOM 去 Render。我相信這個還是比較麻煩的，不過這並不是缺點（因為 React 也需要你去聲明 JSX，jQuery 你也可以用模式統一一下 render），其中有一個缺點就是，要去選擇是直接綁定事件呢？還是代理一下（非同步的情況），事件以及一些資源的回收問題，小項目至少要回收下事件吧。很容易出現代碼越寫越大，代碼無約束，到處都是不一樣的代碼的情況，即使有模式，因為它並不報錯。

－Vue 1.x 因為目前我還沒有用到 2.0，1.x 應該已經是不錯的版本了，能夠很好的實現 VM 那層的綁定問題，小項目應該不用 Vuex 就可以使用吧，不過跨相鄰組件的時候會多幾個監聽器對象。使用指令可以減少命令式代碼量，直接聲明可實現。

對了，如果你用 jQuery 來實現模式，應該要引入一個模版引擎，EJS 靠近 JS 語法，jQuery.tmpl 和 mustache 需要單獨來了，React 的 JSX 基本和原生拼接沒什麼差別。Vue 2.0 已經引入 JSX，不過對於分號要注意。當然，你要服務端渲染不討論了。

小項目不討論其他框架，應該夠用了吧。

（2）中型項目：這個就分兩種情況。

一、項目要長期發展

二、不需要長期發展的夭折項目

先說第二種，都要夭折的項目。。。選型不用考慮太多，適合團隊成本就好。

1. 看看項目的兼容性，主要看下 IE 的情況，大體選擇如下

Vue 1.x =&> IE9+

React 15-（不包括 15.0） =&> IE8+

React 15+ =&> IE9+

avalon（非IE10+版本） =&> IE6+

avalon（IE10+）=&> IE10+

angular （1.2-）=&> IE8+

angular（1.4左右）=&> IE9+

angular 2 =&> 未大部分了解，可以移步官網

2. 看下項目成員情況

是否都會某一個技術，並且能夠再出現稍大問題上能有相應的經驗。

3. 再看技術信仰

喜歡單向數據流，函數式偏重 =&> React

喜歡雙向數據流，減少一些不必要的代碼在 JS 入口 =&> Vue、avalon、angular

喜歡完善的 API =&> React、Vue

。。。我靠，編不下去了～我是偏向 React. 中小型項目隨意，不過長期發展的中型項目也頂得上一個大型項目（除非你家公司不想長期發展了，或者每次重新開發一套，那成本可高了），就這醬紫，偏執很重要。

---

react非常好，redux也非常好，目前看存在的問題是：redux傾向於函數式編程，高階函數等都不好理解，影響開發效率，這一點需要改進。但是，react和redux本身就不是強耦合的，或者說是自由組合的關係，我們會很樂意看到另一個更簡單易用，更容易被工程項目成員接受的redux出現

---

不看好 React，原因看這裡：『為什麼我要唱衰 React』。

---

推薦閱讀：