【itlr的回答(29票)】:
我們需要技術(shù)棧提供好用的模塊化方式，可以是Web Component，可以是非Web Component的某種機(jī)制，不管什么庫或者框架，我們需要技術(shù)賦予我們完成一個(gè)抽象，一次構(gòu)建，多處復(fù)用的能力，并且這個(gè)過程不能太麻煩，不能做個(gè)很日常的抽象翻半天文檔。
我們需要數(shù)據(jù)綁定，在各種粒度上真正實(shí)現(xiàn)事件驅(qū)動(dòng)，因?yàn)檫@樣我們就不用自己重復(fù)手寫本質(zhì)上并不依賴場(chǎng)景的從視圖到數(shù)據(jù)從數(shù)據(jù)到視圖的自動(dòng)更新，否則我們就得自己操作DOM，優(yōu)化DOM操作，還要自己維護(hù)狀態(tài)，一自己維護(hù)狀態(tài)，就要陷入狀態(tài)同步的漩渦，浪費(fèi)大量時(shí)間和精力。
我們需要技術(shù)棧隱藏掉平臺(tái)的微妙差異，寫一段代碼可以真正實(shí)現(xiàn)跨平臺(tái)，而不用我們自己糾結(jié)于那些本不該應(yīng)用開發(fā)糾結(jié)的事，我們需要持續(xù)穩(wěn)定的跨平臺(tái)支持，最好的移植就是不用移植，這在商業(yè)上有很大的價(jià)值。
我們需要庫或者框架好學(xué)，好用，從第一天起就能快速開發(fā)，而不是不得不經(jīng)歷幾個(gè)月的學(xué)習(xí)曲線那種，因?yàn)榇蠖鄶?shù)團(tuán)隊(duì)的程序員水平都存在梯度，我們不希望因?yàn)橐粋€(gè)技術(shù)棧把初學(xué)水平的人擋在門外很久，理想的狀態(tài)是技術(shù)本身能對(duì)招聘工作完全透明，同樣的工期，同樣的項(xiàng)目，隨時(shí)找人都可以，招人的時(shí)候不用寫得過于具體，只要會(huì)JavaScript就能快速上手，我們需要概念負(fù)擔(dān)盡量少的技術(shù)棧，真正理解了Simplicity的技術(shù)。
我們希望技術(shù)棧有非常好的性能，性能的水平和垂直擴(kuò)展性都很好，這樣我們就不用項(xiàng)目寫到一半回頭去糾結(jié)應(yīng)用開發(fā)團(tuán)隊(duì)很難解決的性能問題，我們需要在快速開發(fā)和基礎(chǔ)性能之間平衡得很好的工具，而不是因?yàn)橐獜?qiáng)調(diào)某一方面而對(duì)另一方面關(guān)注太少的那些工具。
我們需要使用的工具有專業(yè)的團(tuán)隊(duì)或者社區(qū)持續(xù)地跟進(jìn)，最好這些團(tuán)隊(duì)和社區(qū)自己就把自己的東西投入生產(chǎn)使用的技術(shù)，這樣至少對(duì)我們來說風(fēng)險(xiǎn)就有起碼的控制。我們不需要那些心血來潮，永遠(yuǎn)不成熟因?yàn)橛肋h(yuǎn)沒有專門投入的技術(shù)。
我們需要那些普通人喜歡用，也用得好的技術(shù)。
React滿足上面的一些方面，不滿足另一些方面，和其他工具一樣。你需要React，是因?yàn)閮牲c(diǎn)
第一，你充分評(píng)估了你的項(xiàng)目，理解你要解決的問題是什么，是快速開發(fā)，性能，團(tuán)隊(duì)的ergonomics，多數(shù)情況下要解決的問題是多個(gè)要素的平衡
第二，你充分評(píng)估了React這個(gè)棧，理解它是解決你的具體問題的最佳工具，你真的理解了自己的場(chǎng)景中非用React不可的那些事情
如果你覺得React快所以需要，事實(shí)是React并沒有那么快，尤其是大型應(yīng)用，小型應(yīng)用里快是不重要的，所有的框架都足夠快。
如果你覺得React開發(fā)快所以需要，事實(shí)是React并一定是最好用的，尤其是當(dāng)你考慮了團(tuán)隊(duì)的構(gòu)成。
如果你覺得React是Facebook開發(fā)的所以需要，我的揣測(cè)是經(jīng)歷過一個(gè)社區(qū)adoption的高峰以后，F(xiàn)acebook未必能解決剩下的那1%的問題。
如果你覺得React Native很火所以需要，這或許是一個(gè)理由，但RN也不是唯一選擇，從各方面評(píng)估，NativeScript這樣的棧并不比RN壞多少，也許還稍微好一點(diǎn)。如果是大預(yù)算的商業(yè)開發(fā)，RN甚至不應(yīng)該成為首選。
【尤雨溪的回答(219票)】:
首先題主要區(qū)分兩個(gè)概念：React 本身和 React 生態(tài)圈所推崇的主流應(yīng)用架構(gòu)。
React 本身其實(shí)還算簡(jiǎn)單的。最簡(jiǎn)單的理解，一個(gè)組件的渲染函數(shù)就是一個(gè)基于 state 和 props 的純函數(shù)，state 是自己的，props 是外面來的，任何東西變了就重新渲染一遍，是不是很簡(jiǎn)單？
但是，如果拋開 React 生態(tài)圈現(xiàn)在所有的那些東西，只用 React 本身來做個(gè)大型應(yīng)用，你 hold 得住么？我可以打包票，99% 的開發(fā)者 hold 不住。因?yàn)榇笮蛻?yīng)用會(huì)帶來很多規(guī)模上的復(fù)雜度，比如跨組件通信，多組件共享狀態(tài)，多人協(xié)作的可維護(hù)性，大量嵌套組件的性能問題... 等等。這些東西如何處理，都是靠前人填坑才一步步產(chǎn)生了今天的各種設(shè)計(jì)模式。Flux/Redux 的繁瑣，本質(zhì)上是針對(duì)大型應(yīng)用的復(fù)雜度所作出的權(quán)衡：用繁瑣一些的 API，換長(zhǎng)線的可維護(hù)性。在規(guī)模不夠大的應(yīng)用里，這些問題并不那么明顯，那么這些繁瑣的 API 也就顯得有些過度設(shè)計(jì)了。
Dan Abramov 自己在推上多次強(qiáng)調(diào)過，Redux 的設(shè)計(jì)是以幾個(gè)原則為優(yōu)先的：要讓狀態(tài)的變化可追蹤，可重復(fù)，可維護(hù)。為了達(dá)成這個(gè)目的，才會(huì)有 reducer, action, action creator, middleware 這些概念。本來一個(gè) callApi(res => a.b = res) 可以做到的事情，現(xiàn)在你需要先寫全套然后配上 thunk middleware 才能做到。因此在規(guī)模不夠的應(yīng)用里使用 Redux 肯定會(huì)覺得殺雞用牛刀。然而 React 生態(tài)圈里面之前并沒有適合中小規(guī)模應(yīng)用的狀態(tài)解決方案，因?yàn)?Flux 從一開始就是沖著 Facebook scale 去設(shè)計(jì)的，并沒有考慮中小規(guī)模的應(yīng)用。最近 MobX 也算是在 React 生態(tài)圈里搞出點(diǎn)小動(dòng)靜，就是因?yàn)樗钛a(bǔ)了這個(gè)空白，然而用 React + MobX 本質(zhì)上就是一個(gè)更繁瑣的 Vue。
如果做個(gè)比較的話，Vue 本身不加任何庫就可以很好地滿足中小規(guī)模應(yīng)用的需求，配合 Vuex 可以滿足大規(guī)模應(yīng)用的需求。同時(shí)由于 Vue 的依賴追蹤機(jī)制，不管 1.0 還是 2.0 都不存在過渡重渲染的性能問題，shouldComponentUpdate / reselect / ImmutableJS 之類的統(tǒng)統(tǒng)不需要。
其實(shí)本來沒想提到 Vue 的，只是因?yàn)橛行┤说拇鸢咐锩娣且?Vue 來比較。
回到題主最早的問題，我們需要 React/Redux 么？從可維護(hù)性的角度考慮，大型應(yīng)用確實(shí)需要，但這不代表任何規(guī)模的應(yīng)用都得用它，更不代表它就是最好的。如果一個(gè)方案能夠用更簡(jiǎn)潔的方式滿足你的項(xiàng)目對(duì)應(yīng)規(guī)模的可維護(hù)性需求，并且讓你用得爽，那就相信你自己的心，不要因?yàn)?React 教徒云里霧里的宣傳看上去很厲害就盲從。
很多 React 用戶喜歡標(biāo)榜 React is not easy, but it is simple... 我想說，Life is short, easy is underrated.
總結(jié)一下：別人說用得爽，不代表你會(huì)用得爽；自己用得爽的才是真的爽。適合自己（或者手頭項(xiàng)目）的才是最好的。
---
原本的題外話針對(duì)的答案已經(jīng)被踩下去了，我也就不放和題主問題無關(guān)的東西了。
【DolphinWood的回答(30票)】:
看到 @艾瑞克SAYA 和 @aji 在評(píng)論區(qū)吵 css-modules（都怪我?guī)уe(cuò)了方向 233），個(gè)人覺得 css-modules 的方案在很大程度上化解了 scoped css 的問題，但是同時(shí)又限制了 css 的可拓展性，從外部很難修改組件的樣式。
于是在我們的項(xiàng)目中使用了一個(gè)輕量的 theme-able 方案組合GitHub - idiotWu/premodules-loader來化解問題：
使用 themr 構(gòu)造 theme-able 的組件，方便外部拓展，
但是每拓展一個(gè)組件都要建立 style 文件很麻煩，并且有些時(shí)候想要全局樣式化一些組件，所以引入 premodules-loader 在特定場(chǎng)景下通過組合選擇器（.container > $scoped）來進(jìn)行樣式化。
<Login className="login-box"> <Input type="text" placeholder="username"> <Input type="password" placeholder="password"> <Button>Submit</Button></Login>
現(xiàn)在我們想微調(diào) input 和 button 的樣式，如果用 theme-able 的方案的話，就會(huì)變成：
<Login ... theme={loginStyle}> <Input ... theme={userNameInputStyle}> <Input ... theme={passwordInputStyle}}> <Button ... theme={buttonStyle}>Submit</Button></Login>
而使用 premodules-loader 的話（sass 的 hash 真惡心）：
@module '.../input.scss' => $input-comp;@module '.../button.scss' => $button-comp;.login-box { #{map-get($input-comp, 'input')} { // styles for input } #{map-get($button-comp, 'button')} { // styles for button }}然后在 `<Login>` 上再使用 theme 就好，當(dāng)然不使用也可以，隨你喜歡~
順便打下說「針對(duì)框架的痛點(diǎn)，寫個(gè)pull request可好」那位的臉 ;)
======== 以下為原回答 ========
因?yàn)橐婚_始是做 angular 的，前不久面試的時(shí)候被問到：「你覺得 angular 性能為什么比 react 差？」，當(dāng)即一臉黑人問號(hào).jpg，回答說「我沒覺得 angular 性能會(huì)比 react 差到哪去，反而不加控制地去寫的話，react 更容易出現(xiàn)性能問題」。卒。
且不論 jsx 優(yōu)雅不優(yōu)雅，react 給我最明顯的感覺就是從一堆 `ng-xxx` 的指令里解放出來，從此再也不用打開 dev tool 放眼望去全是 directives。
@yjcxy12 提到的
1. Angular的Depency Injection很丑，為了minify還要用array寫兩遍變量名這個(gè)問題不存在，早有 olov/ng-annotate 這樣的解決方案。
2. Angular的module和es6 module兼容性很不好如果我沒理解錯(cuò)的話，這里的 module 指的是 angular 的 dependency injection。這個(gè)也不是多大的問題，就算使用 es6 也要聲明一大堆 import?；蛟S有人說原生的語法更有親和力，然而我們以前在開發(fā) angular 1.x 的時(shí)候也用的完全是 es6 語法，甚至利用一小段 decorator 實(shí)現(xiàn)了 class based controllers。
angular:
react:
4. Provider, Factory, Service其實(shí)是一樣的東西不能一概而論，所有的抽象和定義都是為了讓人更好地讀懂程序。
React 本身并沒有增加多少復(fù)雜度，`propTypes` 的定義避免了很多不必要的防御讓你可以放心地使用值，`state` 也讓組件的狀態(tài)更加清晰明了，不會(huì)像沒有組織過的 angular controller 一樣雜糅了各種變量。但是問題也是存在的：
1. state 的更新不是實(shí)時(shí)的
出于優(yōu)化，react 會(huì)將一個(gè)周期內(nèi)的多次 setState 合并，這就導(dǎo)致了 state 并不是實(shí)時(shí)更新。這個(gè)問題最容易影響到一些互相依賴的計(jì)算，比如我有一個(gè) virtual-list 組件，我想把計(jì)算拆分到不同的 method 里， 于是：
const size = this.getSize();const page = this.calcPage(size);const vl = this.virtualize(props, page, size);
2. 單向數(shù)據(jù)流導(dǎo)致組件內(nèi)外的狀態(tài)難以同步
如同 這篇文章 里描述的，當(dāng)我們想要做一些 mutable components 的時(shí)候，會(huì)碰上 controlled or uncontrolled 的選擇：
按照 react 的設(shè)計(jì)組件多數(shù)應(yīng)該是 stateless 的，即一個(gè) `<Input>` 要受控于 `props.value`，當(dāng)用戶輸入內(nèi)容時(shí)，只能請(qǐng)求上層組件去更新 props，如果上層不搭理你或者不傳入 `onChange` handler，這個(gè)組件就變成 read-only 的死組件了。
若設(shè)計(jì)成 uncontrolled，狀態(tài)全部維護(hù)在內(nèi)部，則使得外部無法主動(dòng)修改內(nèi)部的值。
于是我們只好同時(shí)維護(hù) `props` 與 `state`，憑空增加一堆復(fù)雜度來達(dá)到 DOM 原生般的交互。
相比之下的選擇：
很多人會(huì)僅僅因?yàn)?angular 1.x 已經(jīng)過時(shí)了而選擇 react。確實(shí) react 的項(xiàng)目在代碼的可維護(hù)性和健壯性上有很大的提升，但是這是以更高的抽象作為代價(jià)的（尤其是 redux 之流）。對(duì)于一個(gè)完全不了解 react 和 angular 的創(chuàng)業(yè)團(tuán)隊(duì)來說，如果想要快速開發(fā)我還是會(huì)建議他們用 angular，react 配合上 redux 那一家子以后，很難再想快起來。
然而，我現(xiàn)在寫著 react ;)
最后，時(shí)間會(huì)證明 all-in-js 的做法是不恰的（沒錯(cuò)，說的就是你們 css-modules）。
以上。
來自一個(gè)思想守舊的前端程序員。
參考：
【惡魔的回答(2票)】:
react非常好，redux也非常好，目前看存在的問題是：redux傾向于函數(shù)式編程，高階函數(shù)等都不好理解，影響開發(fā)效率，這一點(diǎn)需要改進(jìn)。但是，react和redux本身就不是強(qiáng)耦合的，或者說是自由組合的關(guān)系，我們會(huì)很樂意看到另一個(gè)更簡(jiǎn)單易用，更容易被工程項(xiàng)目成員接受的redux出現(xiàn)
【題葉的回答(39票)】:
前面有個(gè)很讓我認(rèn)同的演講, 思考的是人們?cè)趺淳幊? 先為對(duì)應(yīng)的問題建立一個(gè)模型, 然后用代碼設(shè)計(jì)出一套 DSL, 再將代碼進(jìn)行運(yùn)算以解決問題.
那么前端 UI 的更新當(dāng)然是 MVC 或者 MV*, 也就是用戶操作增量更新 Model, Model 更新怎樣同步到 View.
比如 MVVM, 也就是 Angular 跟 Vue 采用的模式, 常說的雙向綁定, 就是故意設(shè)計(jì)一些結(jié)構(gòu), 在 View 上操作時(shí)比如點(diǎn)擊一個(gè)節(jié)點(diǎn), 執(zhí)行一個(gè)表達(dá)式更新一個(gè)位置, 雙向綁定意味著界面和數(shù)據(jù)需要盡量做到一一對(duì)應(yīng), 不然的話, 從 View 操作的位置查找 Model 的更新的位置會(huì)有些麻煩(當(dāng)然也不是沒辦法解決, 只是說這不是雙向綁定為了解決的問題):
有了大體的模型, 然后就是做具體的實(shí)現(xiàn), 后面還有填各種模型不適合解決的坑.有了大體的模型, 然后就是做具體的實(shí)現(xiàn), 后面還有填各種模型不適合解決的坑.
比如說 MVVM 前面那個(gè) Object.observe 的事情, 后來總算據(jù)說因?yàn)樾阅芊矫鎲栴}不了了之了. 但回頭看, 為了找到 Model 布局更新的位置, 各種方案也算辛苦了. 這樣解決了 Model -> View 的問題, 在 View 到 Model 也是類似的情況, 所有賦值操作被代理了, 以便觸發(fā) View 的操作.
其實(shí)在我這種 FP 死黨的眼里簡(jiǎn)直是不可思議, 本來還算簡(jiǎn)單的對(duì)象, 全部模擬 Atom 類型(腦補(bǔ)一個(gè) Papi醬表情).
Flux 的套路呢稍有不同, 不是綁定了, View 更新會(huì)映射到一個(gè) Action,至于 Action 怎么更新 Model, 自己寫, 挺麻煩的, 不過這樣的話其實(shí)就不用受到 ViewModel 跟 Model 之間對(duì)應(yīng)關(guān)系的限制了. React 其實(shí)吸收了后端開發(fā)和函數(shù)式編程很多套路. 特別是函數(shù)式編程不可變數(shù)據(jù). 至于 Redux, 在吸收了 Elm 的優(yōu)點(diǎn)以后繼續(xù)把概念往極端上推, 同時(shí)努力跟 ES6 大環(huán)境配合.
坑也不少, 首先 DOM Diff 就是為了適應(yīng)方案而做的, 既然 DOM 是聲明式的 DSL, 更新 DOM 的操作總要寫, 于是通過 DOM Diff 生成出來. 整套方案其實(shí)開銷不小, 于是從 FP 社區(qū)學(xué)了 Immutable 過來, 后面就是讓很多人覺得眼花繚亂到無語的一大串東西.
其實(shí)看兩個(gè)方案, JavaScript 和 DOM 兩者都是被各種折騰的. MVVM 通過將數(shù)據(jù)變成 Observable 來變相實(shí)現(xiàn) Reactive Programming, 也就是多份數(shù)據(jù)之間按照數(shù)據(jù)流自動(dòng)同步, js 原生對(duì)象簡(jiǎn)直弱雞, 干脆整個(gè) hack 掉, 同時(shí) HTML 也 Hack 成強(qiáng)大的 DSL 系統(tǒng). 在 React 這邊也差不多, DOM 需要做 Diff, 也需要依賴 Immutable, 干脆就是 JSX 上來. 對(duì)數(shù)據(jù)類型也不爽, 于是用整個(gè) immutable 模塊替換掉基礎(chǔ)類型. 所以兩個(gè)方案其實(shí)都把 js 那個(gè)了一遍, 建立自己的一整套 DSL.
MVVM 的坑我就不說了, 反正我不喜歡, 我也不會(huì) Java 各種設(shè)計(jì)模式.
React 這邊的問題也不小, 如果你熟悉點(diǎn) FP 主流的語言, 一套 FP 的實(shí)現(xiàn)長(zhǎng)成 React 社區(qū)這幅樣子也真夠累的了. 一切皆是表達(dá)式嗎? js 設(shè)計(jì)的時(shí)候就不是. 不可變數(shù)據(jù)嗎? 不是, 一般都可以改的. 結(jié)構(gòu)復(fù)用方案內(nèi)存優(yōu)化嗎? 沒有, freeze 做不了, 只能自己做. 有隔離副作用的習(xí)慣嗎? 整個(gè)語言遍布副作用. 異步抽象呢? 還在制定標(biāo)準(zhǔn)呢.
結(jié)果呢, React 得到的就是一個(gè)不上不下的方案, 一方面要用到艱澀的知識(shí)點(diǎn)去做高級(jí)的優(yōu)化, 一方面要兼顧 JavaScript 巨大的生態(tài). 跟著其他的事情層出不窮, 可變數(shù)據(jù)和不可變數(shù)據(jù)混在一起用怎么樣? Component state 和 Closure variable 混合使用怎么樣? 在函數(shù)式語言當(dāng)中傾向于在語言層面增加限制, 避免大量出現(xiàn) anti-pattern 影響全局, 但是 React 很難, 你教人寫 JavaScript 還不讓人隨便寫賦值, 哪有這樣的道理?! 然后 React 只能延續(xù)這種混搭風(fēng)了.
你可以找基于 FP 語言實(shí)現(xiàn)的 Flux 的套路, 對(duì)比一下 React 混搭的寫法.
Elm https://github.com/evancz/elm-todomvc/blob/master/Todo.elm
Respo https://github.com/respo-mvc/respo-spa-example
回到原來的問題, 為什么需要 React, 為什么 React 顯得那么越來越奇葩. 我認(rèn)為 React 背后的架構(gòu)方案足夠清晰也經(jīng)得起時(shí)間考驗(yàn), 這很重要. 為什么 React 越來越奇葩, 因?yàn)槭腔齑铒L(fēng).
【yjcxy12的回答(116票)】:
國外現(xiàn)在是React一統(tǒng)世界，不知道知乎上為什么唱衰的比較多。React已經(jīng)大量得被各個(gè)公司各種產(chǎn)品使用，也就是說React已經(jīng)不是未來的技術(shù)，使用React也不能說很潮了。
關(guān)于React的好處，和Angular的比較之類的文章有非常多，大部分是一兩年前寫出來的，現(xiàn)在的文章基本上是React最佳實(shí)踐是什么，React怎么上手之類。可以看出React到底需不需要，到底好不好，和Angular比較起來如何等等都已經(jīng)算是有定論了。你不用該不用，但是從React社區(qū)出來的對(duì)前端巨大的影響是沒法忽視的，React就像是房間里的大象(Elephant in the room)，你不得不面對(duì)它，了解它，深入了解過后還選擇別的框架是你的選擇，不過不了解React及其生態(tài)的核心概念(組件化，虛擬DOM，單向數(shù)據(jù)流，附帶es6，webpack等等)會(huì)讓你覺得你已經(jīng)out了。
至于我個(gè)人使用的 經(jīng)驗(yàn)，剛開始用的時(shí)候的確是有很多字疑問的，用Angular我會(huì)更快做出來的東西，我為什么要用React。用久了就能感覺Angular很清晰的劣勢(shì)
- Angular的Depency Injection很丑，為了minify還要用array寫兩遍變量名
- Angular的module和es6 module兼容性很不好
- Scope chain只能讓人越用越糊涂。Controller as也沒改善太多
- Provider, Factory, Service其實(shí)是一樣的東西
- 目前的最佳實(shí)踐是頁面上所有東西都用Directive,強(qiáng)制組件化(那為啥不直接用React?)
- 侵入性太強(qiáng)，需要學(xué)很多Angular特有的語法，track by, transclude, $開頭的所有變量，scope, promise. http 都必須使用它提供的
而React的優(yōu)勢(shì)，今年React Europe上Cheng Lou的演講就很好的說出來: Html完全不能滿足我們對(duì)于前端app的需求，所以React給了我們?nèi)縥avascript沒有html的方案，這給了我們可以使用完備的程序語言來構(gòu)建頁面的能力，同時(shí)對(duì)于優(yōu)化則是做到最底層minimum DOM diff。
我覺得程序員需要有一種對(duì)一段代碼是否是正統(tǒng)的直覺，比如使用setTimeout(fn, 0)來跳出當(dāng)前執(zhí)行感覺是Hacky而不正統(tǒng)，比如arr.constructor === Array 就覺得沒有 Array.isArray()正統(tǒng)。而使用過這么久React的個(gè)人感覺，React中大部分概念是正統(tǒng)的，是rightful的，遠(yuǎn)比Angular要多。
最后還是再強(qiáng)調(diào)一下React是當(dāng)下前端是繞不過去的坎，已經(jīng)不是不妨了解一下的程度，而是不了解要out了。當(dāng)你深入了解了React，再挑React的毛病，會(huì)讓你可信很多(就像Cycle.js作者一樣)
EDIT:
問題更新了，那就更新一下關(guān)于React本身和生態(tài)吧。
React從發(fā)布起幾年來有過幾次變革，基本上React發(fā)展的時(shí)間和這幾年前端工程化迅猛發(fā)展有很高的重合。記得當(dāng)時(shí)是用React.creatClass定義組件，還是用著es5，用著mixin。而es6的發(fā)展紅紅火火，萬眾所歸，React也適時(shí)得推出es6 class syntax。之后redux帶著函數(shù)式的概念一統(tǒng)各類flux，順帶函數(shù)式呼聲越來越高，React也推出了functional stateless component。
Build tool方面，記得當(dāng)初還是grunt的天下，接著gulp取代其位置，和babel browserify一起接管React項(xiàng)目中各種任務(wù)(transpile js/css, uglify, sourcemap, concat等等)，之后是React和Redux各大神看中webpack能打包多個(gè)文件和hot module reloading的特性全部轉(zhuǎn)入webpack，webpack也的確給力，打包起來比gulp方便，debug又有webpack-dev-server這個(gè)大殺器。
一開始React就是宣傳兩個(gè)概念，組件化和virtual dom，這些基本都被說爛了，而個(gè)人看法除了這兩點(diǎn)，React最大的貢獻(xiàn)一是一直幫助整個(gè)前端進(jìn)入工程化，標(biāo)準(zhǔn)化的時(shí)代(使用virtual dom和jsx轉(zhuǎn)換的library是可以替換React的)，二是將函數(shù)式思想介紹給前端。functional stateless component就是 view=f(state)而redux核心也就是nextState=f(state, action)，也催生了很多函數(shù)式的最佳實(shí)踐，比如action creator和reducer必須是沒有副作用的pure function，比如使用immutable操作(concat,map替代push,forEach)。
要說現(xiàn)在用React做網(wǎng)站設(shè)置繁瑣嗎？當(dāng)然繁瑣，要設(shè)置eslint，babel，webpack，用boilerplate最終還是要了解各個(gè)不同的東西是干嘛的，不過把這些歸罪React也不是太恰當(dāng)，畢竟是整個(gè)前端生態(tài)圈都進(jìn)化了。用Angular 2或者Ember你還是得用到這些。React的繁瑣基本都在redux上，得creatStore還得加入middleware還得用connect()連接到store，而帶來的高階組建的概念不好懂也不容易用。
React有它自己的缺點(diǎn)，畢竟我們上哪找完美的東西呢？Boilerplate過多，setState是異步的，context api很坑爹，server side reder各種坑(設(shè)置hmr，哪些call在服務(wù)器做，哪些只能在瀏覽器運(yùn)行等等)，animation到現(xiàn)在都沒什么太好的方案。
不過React值得用嗎？當(dāng)然值得，它給你組件化頁面，入門函數(shù)式，清晰的單向數(shù)據(jù)流(dispatch(action)->reducer->render)，深入了還有高階組件的composability，能發(fā)現(xiàn)selector和reducer其實(shí)也是composable的，順帶著各個(gè)工具的使用(eslint, babel, webpack)，不小心還能入Elm和Clojurescript的坑。
還有一個(gè)經(jīng)常被提起的好處是React redux做的網(wǎng)站，重構(gòu)非常方便，在需求永遠(yuǎn)不固定的世界里也是一大優(yōu)勢(shì)。
所以，這么多大公司轉(zhuǎn)用React也許不是因?yàn)樗麄兌际巧底?，也許React確確實(shí)實(shí)帶來了好處。
【lfyzjck的回答(4票)】:
討論這個(gè)東西好不好得先討論 3 個(gè)問題：
* 需求
* 組織架構(gòu)
* 維護(hù)周期
如果是一個(gè)簡(jiǎn)單的 H5 頁面，除了傳統(tǒng)的表單也沒什么復(fù)雜的交互，引入 React 開發(fā)起來可能還不如傳統(tǒng)后端渲染方便，這個(gè)時(shí)候用 React 或者什么 AngularJs 都是找罪受。原來 1 個(gè)人能寫完的功能現(xiàn)在得 1.5 個(gè)人。就如題主所說，引入 React 帶來的額外的復(fù)雜性，但是好處對(duì)這個(gè)項(xiàng)目來說可能都沒用。VirtualDOM，F(xiàn)lux 都是Facebook 這種量級(jí)的公司為了解決復(fù)雜應(yīng)用的性能和狀態(tài)管理引入的，所以天貓?jiān)谟?React 用的很爽不代表你的項(xiàng)目引入 React 也很爽。
不過如果你們項(xiàng)目組有至少一個(gè)專職前端，至少一個(gè)專職后端，引入一些前后端分離的框架，讓程序的架構(gòu)和人員架構(gòu)相匹配。雙方可以基于共同的文檔盡早的投入開發(fā)而不會(huì)互相 block 住對(duì)方的進(jìn)度，這樣的效率提升非常有意義。
維護(hù)周期也是類似的道理，如果是一次性的項(xiàng)目，后期不會(huì)有太多需求變化，盡快做完需求才是王道。如果你要跟這這個(gè)項(xiàng)目好幾個(gè)月甚至一直維護(hù)，那是得慎重的再做下選擇，畢竟不能坑了自己。
話說回來，現(xiàn)在不會(huì) React 都不好意思說你會(huì)寫前端了，沒用過的趕緊在實(shí)際項(xiàng)目里嘗試一下，是銀彈還是大坑自己體驗(yàn)一下就知道了。
【OooO的回答(115票)】:
在此聲明一下，只是想通過技術(shù)角度去評(píng)價(jià)框架，并無意去指責(zé)或者去嘲諷其它框架，如某些言論表達(dá)得不恰當(dāng)，請(qǐng)私我，我可刪除。對(duì)于無意義的漫罵或指責(zé)，表示不接受也不回復(fù)。
關(guān)于React的問題，我有幾點(diǎn)要說：
1、React確實(shí)存在組件嵌套的性能問題，但是可以通過Redux去解耦以達(dá)到目的
2、對(duì)于引入immutable / reselect 對(duì)于大部分并不是必需品，組件粒度越細(xì)，state使用得越少，需要引入shouldComponentUpdate的情況越少，其實(shí)在項(xiàng)目中真正有用到它們的有多少呢？
3、React的中大型項(xiàng)目上的應(yīng)用并不是太大的問題，國內(nèi)有Ant.design已經(jīng)在大量的螞蟻金融平臺(tái)和或各類內(nèi)部平臺(tái)上使用，盡管Vue也有，但只是實(shí)驗(yàn)版本，也并沒有再去升級(jí)。 在國外：faceBook算大型應(yīng)用嗎？它本身已經(jīng)就應(yīng)用了React 16 Alpha 版本，以身試坑，這樣算得上 React 在大型應(yīng)用上有問題嗎？
4、React是有門檻的，確實(shí)沒有Mv**那么快讓人容易接受，需要有一定的JS基礎(chǔ)和開發(fā)經(jīng)驗(yàn)。
5、對(duì)于理解Redux，有些人需要些更多的時(shí)間去理解，有些人卻能夠在短時(shí)間快速掌握，同樣是在中小型應(yīng)用中，確實(shí)是有些繁瑣，可是我們同樣可以通過Redux-Actions去簡(jiǎn)化這些繁瑣。最簡(jiǎn)的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
注： 在中小型應(yīng)用中，這么寫法，算很復(fù)雜嗎？難以理解嗎？推薦您往下讀讀我對(duì)Redux的理解。
再一次題外話：很認(rèn)可Vue本身帶來高效率的開發(fā)和很低的學(xué)習(xí)曲線，并認(rèn)可作者的努力，也覺得Vue未來能夠給大家?guī)砀鄡?yōu)秀的特性，但是我們不能夠忽略Vue及Mvvm本身存在的問題，同時(shí)也是希望我的分享能夠給大家?guī)韨€(gè)人對(duì)框架的體驗(yàn)。
我是從0.12版本開始使用Vue的，大概使用7個(gè)月+吧。開發(fā)的項(xiàng)目本身更多的是通過自定義控件，讓用戶更快的構(gòu)建自己的游戲管理，已經(jīng)接入了數(shù)十款游戲，游戲本身給公司帶來的收入達(dá)到數(shù)億計(jì)。我不敢妄自菲薄稱該項(xiàng)目是大型項(xiàng)目，僅僅只是一個(gè)中小型級(jí)別的項(xiàng)目，我來說說在這項(xiàng)目中使用Vue帶給我的體驗(yàn)。
1、Vue確實(shí)簡(jiǎn)單，文檔非常清晰親民，可是API數(shù)量太多，數(shù)次遇到的問題都是因?yàn)閷?duì)API的不熟悉，同時(shí)概念太多，盡管完成了項(xiàng)目，但是很多地方邏輯處理得不是很讓人舒服
2、翻開代碼，我依然看到我不成熟地使用inherit特性所導(dǎo)致繼承組件帶來更多無意義的變量，常常因?yàn)橐粋€(gè)變量的變化，常常影響子組件的屬性，直到API官網(wǎng)出現(xiàn)了最佳實(shí)踐，方知自己錯(cuò)誤的實(shí)踐。
3、滿屏的的v-mode / $watch / $on / $emit / $dispatch / $set / this.var 讓我們調(diào)試問題變得更復(fù)雜，因?yàn)槲也恢谰烤箶帱c(diǎn)該斷在哪個(gè)位置，還是在視圖才能夠更快的找出問題，因?yàn)槲乙婚_始覺得使用它們是更輕松、更舒服的方式。我相信作者也敏銳的發(fā)現(xiàn)了這個(gè)問題，把$dispatch在2.0給移除掉了。
4、更為神奇的是，我在文本框以及它的父組件使用v-model時(shí)，發(fā)現(xiàn)輸入中文，發(fā)現(xiàn)中英文同時(shí)出現(xiàn)文本框里，我發(fā)現(xiàn)這個(gè)問題是在于我使用0.12.6 之后的版本才會(huì)出現(xiàn)，而0.12.6本身并不會(huì)有這樣的問題，當(dāng)然最后我使用了 v-on keyup 來解決了。我相信是我的使用姿勢(shì)不太正確。
5、Vue.Compnent / Vue.Extend / ViewModel 它們的 options 重疊相同的部分太多，在項(xiàng)目中每個(gè)人都有自己喜歡使用的方式，假如不合理使用，可能導(dǎo)致，各種data不合理的出現(xiàn)在不同的位置。
Vue確實(shí)是一個(gè)優(yōu)秀的新秀，使用它，你并不需要擔(dān)心有比較嚴(yán)重的bug或者性能問題，但是你仍然要擔(dān)心的是在大量的刪改API情況下，我如何從0.12遷移到1.x，2.0， 我有想過，我被1.x那些優(yōu)異的API所感到新奇和驚喜，但是大量地使用 inherit 導(dǎo)致更新起來邏輯調(diào)整更困難了。
相信作者對(duì)于JSX，還是有一定相法的，不然也不會(huì)去在2.0引入JSX。而恰恰地，存在一個(gè)問題，框架本身帶來的可選項(xiàng)太多，我們?nèi)绾慰焖俚淖R(shí)別它們帶來的副作用，讓我們?nèi)绾翁峁└鼉?yōu)雅的方式去使用框架。那么同樣的問題也存在了，究竟我們是選擇JSX 還是 template呢？
而Vue 2.0刪改了哪些API呢？我很無聊地去數(shù)了下，大概有30+的API，我例舉下些可能大家可能曾經(jīng)會(huì)用到的部分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
我們相信作者刪除它們是為了簡(jiǎn)化API的負(fù)擔(dān)，可是這些API，是否又能夠輕松的從項(xiàng)目中遷移呢？特別是DOM，相信大家自有定論。
同時(shí)React也存在，使用它周圍哪些庫更輕松更簡(jiǎn)便更合理地開發(fā)呢？可幸好，它們是可選項(xiàng)，而 Redux也僅有2K代碼量，想要重新實(shí)現(xiàn)它帶來的思想是一件很輕松的事。
使用React，讓我感受到組件本身帶來強(qiáng)內(nèi)聚，搭積木式的組裝體驗(yàn)，通過 render 函數(shù)更直觀的看到 DOM 結(jié)構(gòu)，這也是為什么我使用 React 的原因。
我并不排斥任何新框架，新事物，對(duì)于任何框架我很欣賞也很欽佩框架作者的技術(shù)能力，但是我仍然不想忽視框架本身存在的問題，因?yàn)闆]有完美的框架，只有適合的應(yīng)用場(chǎng)景，選擇自己更適合的，不是嗎？
====================================
題主亂帶節(jié)奏，帶偏一幫老司機(jī)飚車飚錯(cuò)了方向，我就我有限的經(jīng)驗(yàn)聊聊React解決什么痛點(diǎn)，以及我們?yōu)槭裁葱枰伞?/p>
在此之前，我先做個(gè)聲明：
框架都是為了提供某類開發(fā)場(chǎng)景而生的，性能只是加分項(xiàng)，再厲害的框架也牛不過原生擼碼！
現(xiàn)在主流的框架（主要以React/Vue/Angular為背景）都主要以有限數(shù)據(jù)狀態(tài)機(jī)來解決復(fù)雜的交互應(yīng)用場(chǎng)景、編寫可控可復(fù)用的代碼以及開發(fā)效率問題。而它們所謂的繁瑣是相對(duì)于應(yīng)用場(chǎng)景和人的。
題主說到React繁瑣，指的是他并沒有理解Flux/ReFlux/Redux為什么要擼那么多代碼來實(shí)現(xiàn)原來僅僅只需要$.ajax就可以實(shí)現(xiàn)的數(shù)據(jù)交換以及組件間通訊問題。
其實(shí)我恰恰認(rèn)為它們（Flux/ReFlux/Redux）并沒有 優(yōu)雅地解決數(shù)據(jù)交換以及組件間通訊（不喜勿噴），在我的項(xiàng)目中我已經(jīng)拒絕再去使用它們，那樣React變得更輕量了？
可我們依然要面臨組件間通訊繁瑣的問題：
1、通過父組件通過給子組件傳遞函數(shù)到Props，重繪父組件達(dá)到更新兄弟或兄弟的子孫組件達(dá)到目的。但是，重繪父組件會(huì)導(dǎo)致其所有無需更新子組件重繪，同時(shí)可能導(dǎo)致被動(dòng)更新的子組件某些與props有關(guān)聯(lián)的state 被更新（state丟失）。只能通過ShouldComponentUpdate 者componentWillReceiveProps去解決此類問題。對(duì)于孫子以下的組件更新更加繁瑣及麻煩。
2、通過一個(gè)中轉(zhuǎn)容器去解決跨組件通訊問題（例如EventEmit/Redux等），但EventEmit卻沒有更好地解決數(shù)據(jù)與視圖分離，以及Event本身帶來的閉包、隱含邏輯依賴關(guān)系和時(shí)序問題（通俗的說，項(xiàng)目大了，不同對(duì)象的不同的事件名稱、參數(shù)和調(diào)用關(guān)系變得很亂）需要有一個(gè)很合理的解決方案。
而我們，只不過想把某些個(gè)數(shù)據(jù)發(fā)送到指定的組件里執(zhí)行。而我認(rèn)為吸取Event/Redux等的經(jīng)驗(yàn)。我們可以這么做：
1、提供一個(gè)數(shù)據(jù)容器，所有數(shù)據(jù)都直接發(fā)送到該容器，這樣我們可以輕松做到Redux的可預(yù)測(cè)和可回溯。
2、關(guān)聯(lián)組件所需的數(shù)據(jù)到該數(shù)據(jù)容器。
3、約束數(shù)據(jù)發(fā)送時(shí)，接收組件的父級(jí)及子級(jí)不允許被更新（很多人在做組件設(shè)計(jì)時(shí)，父組件接收數(shù)據(jù)A的KEY1,KEY2，而自己接收數(shù)據(jù)A的KEY2和KEY3，這樣是錯(cuò)誤的設(shè)計(jì)，應(yīng)該把接收數(shù)據(jù)A的KEY1,KEY2的內(nèi)容拆成一個(gè)子組件接收）
等等，這不是和Redux差不多嗎？
NO, NO, NO, NO，請(qǐng)耐心聽我說完。
差異在于：
1、我們只發(fā)送數(shù)據(jù)，不需要定義ActionType等等
dispatch({ key1, key2})
dispatch({ key1, key2}, reducer)
注：reducer是可選項(xiàng)。
這樣我們便可以很輕松地，將它們封裝起來
dispatchUser = paramter => {
// promise.all(login, xx).then(..)
// fetch(json).then(..)
// dispatch(json, state => object.assign({}, state, json))
dispatch(json)
}
2、配置接收數(shù)據(jù)的組件
connect( state => ({ key1, key2 })(componentA)
class componentA {
getStore(state) {
this.setState( { key1: state.key })
}
}
注：假如你想默認(rèn)直接更新，稍微包裝一下就實(shí)現(xiàn)自動(dòng)setState。
具體代碼我最近還在開擼了，擼好了，再告訴大家。
當(dāng)然使用Redux，可以借助Redux-Actions去簡(jiǎn)化我們的實(shí)現(xiàn)。具體可看：GitHub - acdlite/redux-actions: Flux Standard Action utilities for Redux.
選擇React：
1、我們可以使用最簡(jiǎn)單的JSX方式去封裝我們的組件，我們只需要關(guān)注我們需要接收什么數(shù)據(jù)，以及展現(xiàn)什么內(nèi)容， <Component A={} B={} /> 多么直觀啊
2、只要熟練JS，就能夠很輕松實(shí)現(xiàn)絕大多數(shù)模板語法的內(nèi)容
3、因?yàn)锳PI足夠少，我們有更靈活的發(fā)揮空間
4、開發(fā)環(huán)境下，足夠豐富的錯(cuò)誤提醒
5、React版本迭代遷移，工作量并不大，有遷移提醒，API刪改少量且遷移成本低
6、不會(huì)引入大量的概念到React庫里，保持純凈，其它周邊庫都是可選項(xiàng)。
也有人質(zhì)疑JSX，寫起來不是那么的好看和直觀，其實(shí)寫多了，你會(huì)逐步體驗(yàn)到它帶來的好處。例如分支判斷可以拆個(gè)無狀態(tài)組件等等。
未來可能會(huì)有更多優(yōu)秀的框架，但目前，選擇React仍舊是一個(gè)不錯(cuò)的選擇，不排斥Vue，但是 API 不斷的刪改，引入的概念這么多，如何根據(jù)這些概念給出一個(gè)最佳實(shí)踐到項(xiàng)目中到團(tuán)隊(duì)中呢？這又是一個(gè)新的問題
題外話：
假如您只是一個(gè)營銷類的推廣頁面，僅僅只有輪播、幾個(gè)文本框的表單的極淺交互，我還是推薦大伙使用原生 / zepto / jQuery之流。
假如您很在意體積，計(jì)較網(wǎng)絡(luò)環(huán)境（2G/3G）等，可以使用服務(wù)器端渲染或者無阻塞UI（即添加占位符），使用帶有GZIP的CDN，React各類庫絕對(duì)能夠在100K以內(nèi)，假如超過，建議您使用按需加載。我相信您的服務(wù)器應(yīng)該會(huì)添加有304/ETAG之類的緩存。
對(duì)于中大型項(xiàng)目，React確實(shí)是優(yōu)良之選，當(dāng)然也可以嘗試Vue去迭代中小型項(xiàng)目。
=====================================================================
做為一個(gè)在從Angular到Vue， 最后選擇React，并有實(shí)際項(xiàng)目經(jīng)驗(yàn)的人告訴你。React我們需要它。
框架都只是為了開發(fā)效率和良好地組織項(xiàng)目代碼，并不完全是為性能而生！
框架都只是為了開發(fā)效率和良好地組織項(xiàng)目代碼，并不完全是為性能而生！
框架都只是為了開發(fā)效率和良好地組織項(xiàng)目代碼，并不完全是為性能而生！
對(duì)于只會(huì)Copy/Paste的人，很好奇，他如何很好的維護(hù)那糞池？
Angular1.x 那些丑陋的特性，其實(shí)可以用ES6 或者 Typescript 進(jìn)行二次語法包裝，一樣能夠?qū)懙煤芷恋?，隱藏很多讓人無奈的細(xì)節(jié)。具體可以看：GitHub - ulfryk/angular-typescript: TypeScript 1.7 annotations (decorators) for AngularJS 1.x
這些僅僅只是有限的包裝，你可能還需要包裝更多更多的特性，不過這樣真的好嗎？
Angular 2.0.0 rc.4 （目前確認(rèn)的最新版本） 已經(jīng)醞釀了一年多了，語法幾乎完全脫離了1.x版本。它似乎要把目前主流框架和特性都要集合到一塊，如vdom、rxjs、typescript等等，源碼模塊引入了rollup去打包框架代碼，業(yè)務(wù)代碼依然是webpack。 然后我們默默地打開一下它的API文檔，數(shù)百個(gè)API指令（請(qǐng)容許我夸張地虛報(bào)了個(gè)數(shù)字），如此大而全的框架，讓人唏噓不已。依然延續(xù)了1.x的繁瑣復(fù)雜的語法，當(dāng)然我們不能否認(rèn)它們的一鍋端設(shè)計(jì)，只不過適用的場(chǎng)景實(shí)在是有局限性，Ionic2這個(gè)Hybird端的老搭舊已經(jīng)率先同步了。
盡管Typescript強(qiáng)健了我的代碼，提升了我的開發(fā)效率；
盡管Rx革新了我的數(shù)據(jù)流，完美地封裝我代碼中那些不完美的代碼邏輯
但是... 我依然沒有辦法再去學(xué)習(xí)這幾百個(gè)API。
Vue相當(dāng)不錯(cuò)，從一開始是一個(gè)簡(jiǎn)化版的Angular1.x，一年內(nèi)從0.x 一直 飚升到 2.x ，作者一人撐起了80%+的生態(tài)，幾乎覆蓋現(xiàn)在主流的特性和小庫。性能一直號(hào)稱業(yè)界姣姣者。
等等，我們好像忽略了什么？
Vue 1.x 到 2.x 開始閹割大量API和模板語法。讓一直追隨他的小粉絲的我，開始懵筆了，我的Vue項(xiàng)目已經(jīng)開始準(zhǔn)備1.3，1.4的功能開發(fā)了，而我卻只能使用0.x 看著別人快樂地用著1.x， 2.x 擼啊擼。
看著作者愉快地將某些個(gè)模板、某些個(gè)生命周期、某些個(gè)事件等等語法一而三，再而三地不斷地改啊改啊的，還能愉快地跟得上這股風(fēng)么？
與此同時(shí)Vue開始在2.x引入JSX的語法， 開始有點(diǎn)走Angular2小邪路，對(duì)于某些新人來說，我開心地時(shí)候想用JSX，不開心地時(shí)候，我喜歡用Template語法。這樣的可選項(xiàng)是否合適呢
不得不說，Vue的生態(tài)、文檔、性能等等各方面都都是業(yè)界的姣姣者，只可惜Vue只適合中小型項(xiàng)目的開發(fā)，已經(jīng)開發(fā)夠快，夠穩(wěn)定，概念夠新，適合快速迭代的項(xiàng)目，但是對(duì)于中大型項(xiàng)目需要的是穩(wěn)定....
修正一下，有人說vue2.x哪里支持JSX，先曬曬作者微博上的圖（侵刪）：
看完上圖是不是感覺和React相似度已經(jīng)60%+了？當(dāng)然還有*.vue/vue.component，是否作者是考慮讓用戶安穩(wěn)的過渡到JSX？還是維護(hù)JSX和Template呢？那么最佳實(shí)踐是什么呢？
React 是唯一一個(gè)讓我真正體驗(yàn)到編寫代碼快感和舒適感。（盡管在此之前我很排斥JSX）
簡(jiǎn)約的語法，輕量的API，組織代碼時(shí)的穩(wěn)健，時(shí)時(shí)刻刻讓我爽到溜起....
怎么簡(jiǎn)約輕量？可以看這里多個(gè)主流框架的語法對(duì)比：Front-end Hyperpolyglot
穩(wěn)定的API，每次升級(jí)都是在強(qiáng)化和優(yōu)化，相當(dāng)少少少少量的API更新，即將廢棄的語法，都會(huì)有警告提示，讓我們更快的升級(jí)架構(gòu)。
flux/reflux/redux 不僅僅只能用在React，也能用在Vue/Angular等等框架，僅僅只是一個(gè)數(shù)據(jù)流思想，您選擇性地使用。
其實(shí)概念很清晰，舉個(gè)Apple云很簡(jiǎn)單的例子來形容Redux：
我們的設(shè)備（Iphone/Ipad/Mac）的照片、文檔等信息，都發(fā)送到云端。而我們關(guān)聯(lián)云端的設(shè)備，當(dāng)云端有數(shù)據(jù)更新，就會(huì)自動(dòng)更新到有關(guān)聯(lián)的設(shè)備或應(yīng)用里。
而我們所說的Action 就是我們點(diǎn)擊數(shù)據(jù)發(fā)送云端的指令；
而我們所說的Reducer就是接口，我們需要上傳照片和文檔，都需要轉(zhuǎn)化到 成云端可以接收的數(shù)據(jù)格式。比如圖片，需要轉(zhuǎn)成二進(jìn)制等等。
而云端就是我們所說的Store，存儲(chǔ)了數(shù)據(jù)，很自然的，我們可以在云端查看數(shù)據(jù)上傳歷史，還原某一條數(shù)據(jù)歷史等等，當(dāng)然更多可以想像的功能，都可以在云端實(shí)現(xiàn)。
而我們需要實(shí)現(xiàn)React-Redux / Vue-Redux / Angular-Reudx 等等給到給到各個(gè)設(shè)備接收數(shù)據(jù)。
例如React的Connect，代碼連接到云端接收數(shù)據(jù)并更新到組件。
React/Redux并不是沒有坑：
1、setState 大量數(shù)據(jù)時(shí)（如700多條的列表），會(huì)有點(diǎn)點(diǎn)卡頓，當(dāng)然我們可以通過優(yōu)化得到解決
2、父組件更新某個(gè)子組件數(shù)據(jù)時(shí)，需要父組件重新組織，會(huì)導(dǎo)致其它子組件重新組裝，雖然有vdom，但是這樣顯得不那么人性化。而且某個(gè)子組件內(nèi)部有某些個(gè)state需要保持時(shí)，會(huì)丟失。需要shouldComponentUpdate..，當(dāng)然你可以把組件的數(shù)據(jù)state=》子組件的props設(shè)計(jì)得更淺一些，至多2-3層，使用 redux，只connect具體需要更新數(shù)據(jù)的組件，粒度越細(xì)越好，保證單個(gè)state只更新到一個(gè)組件，這樣還能帶來易組裝的好處。當(dāng)然粒度越細(xì)，自然代碼量也上來了，你也可以采用 stateless（無狀態(tài)）組件去簡(jiǎn)化代碼。各中取舍，取決于您的設(shè)計(jì)。
3、React-Redux經(jīng)常在更新時(shí)，會(huì)產(chǎn)生過渡使用的問題，比如說父組件和子組件都connect，結(jié)果會(huì)導(dǎo)致第2點(diǎn)所說的狀態(tài)丟失和重復(fù)render問題，還會(huì)有數(shù)據(jù)穿透的問題，因?yàn)閏onnect只比較一層state。這時(shí)引入immutable能夠帶來較好的效果，不過個(gè)人認(rèn)為完全沒有這必要。已經(jīng)有大量大神使用Event的方式去解決此類問題。而我，正在考慮擼個(gè)類似于Redux的方案。
總得來說，你需要React，它并不復(fù)雜，而是你聽到的噪聲太多。
對(duì)于大型項(xiàng)目，推薦 Webpac 2 來構(gòu)建業(yè)務(wù)代碼， Rollup 來打包你的小輪子。使用Rx優(yōu)化你的數(shù)據(jù)流。Typescript強(qiáng)健你的代碼，提升你的開發(fā)效率（頭一周可能會(huì)有些痛苦）。但在此之后的收益是非常高的
對(duì)于中小型項(xiàng)目，推薦React/Redux/React-Router來構(gòu)建你的代碼
不要擔(dān)心體積，因?yàn)镃DN都有GZIP，能夠壓到原體積最高22%比例。
不要擔(dān)心打包慢，因?yàn)橥ㄟ^優(yōu)化 webpack，開發(fā)環(huán)境全量打包能快到 5秒， 生產(chǎn)環(huán)境能快到12秒。（vendor 5m 業(yè)務(wù)代碼2m多）
不要擔(dān)心噪聲多，正因?yàn)槿绱?，你的提升才?huì)變得更快。
不要擔(dān)心性能問題，因?yàn)?0%+的場(chǎng)景下，你并不需要考慮性能問題。
不要開發(fā)效率問題，前人種樹，后人乘涼的感受，會(huì)讓你更舒適。
不要說React復(fù)雜，因?yàn)楸绕餉ngular、Vue要簡(jiǎn)單些。只不過沒有更好的最佳實(shí)踐和文檔，所以你迷失了。
React 有 Flux/Reflux /Redux ，你只需要選擇 Redux，Vue也同樣有Vuex
React 需要 webpack / es6 等， Vue也同樣需要webpack / es6，只是有它有 Vue-cli架手腳，但是React也有各種boilerplate。
再比如最新的 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.
請(qǐng)Vue/Angular粉不要罵我，我就照我的經(jīng)歷說，有什么說得不對(duì)，還望糾正。
【CodeDiy的回答(0票)】:
1 結(jié)構(gòu)組織:
一個(gè)是js中嵌入html代碼。
一個(gè)是html嵌入待解析的js指令。
2 學(xué)習(xí)的曲線:
html中嵌入js指令的，界面效果的結(jié)果直觀性好。對(duì)于習(xí)慣了html代碼的，具有一定的好感，這也是vue，angular受眾多的原因。
而js中嵌入html代碼，對(duì)于js基礎(chǔ)功能扎實(shí)的，學(xué)習(xí)起來也很輕松。
3 解決痛點(diǎn):
這種框架適合于大型，中型規(guī)模的業(yè)務(wù)項(xiàng)目。
省去了大量的節(jié)點(diǎn)操作控制邏輯組織。
如果項(xiàng)目較小，學(xué)習(xí)成本大于開發(fā)成本。
4 實(shí)現(xiàn)思路:
react思路更為清晰，概念雖然新，但是層次清楚，偏向于一種函數(shù)式風(fēng)格。
angular，vue等的ob模式，更多的是在面向?qū)ο笠延械脑O(shè)計(jì)模式基礎(chǔ)上發(fā)展來的。各個(gè)概念間關(guān)系更為緊密。
ps:react的源代碼讀起來實(shí)在不舒服，推薦閱讀infernojs這個(gè)框架。實(shí)現(xiàn)接口基本一致，而且代碼兼容。
聯(lián)系客服
