React解決了前端開發中的哪些痛點？
下面我分一下邏輯來詳述一下我對這個問題的見解。
1. 前端開發中會有哪些問題需要考慮
2. 目前解決這些問題的技術方案
3. React 技術棧對上述問題的解決
一、前端開發中會有哪些問題需要考慮
討論這個問題我覺得應該回到問題的本質 -【前端開發會考慮些什么問題】，這些問題即是前端開發過程中的痛點也是難點，了解了這些問題才能知道為什么會有 React 出現，以及 React 如何解決這些問題的。
首先，對于一個前端團隊來說，在進行前端技術規劃的時候都應該考慮的事情：
組件庫、模塊化
開發效率
運行效率
可維護性
體驗優化
組件庫、模塊化
首先是組件庫，任何一個前端業務團隊都會做的事情就是沉淀組件，公共基礎組件，業務組件，函數工具庫，這對于業界的前端來說是共識。 組件庫也就是輪子庫，是提高團隊開發效率的最好方式，同時也是團隊的基礎沉淀（拿 KPI 的絕佳幫手）
然后是模塊化，在幾年前，經常會看到一個 js 幾千行的情況，但是基于可維護性和重用性的考慮，會把js 拆分成模塊，模塊化的需求已經很普遍，出現了很多如 `AMD` `CMD` `CommonJs` `UMD` 這些規范，以及 `require.js` `seaJs` `Browserify` `webpack` 這些工具和庫來解決這些問題。
開發效率
開發效率是前端團隊對業務響應速度的反饋，如果一個業務交給前端團隊過后幾個月都沒有結果那必然會引起上下游的不滿， 不管技術做的多棒，選什么框架，最終的目的都是完成業務。 那哪些因素會影響開發效率呢？
1. 業務代碼架構設計
2. 可重用模塊和組件
第一點是業務代碼的架構設計，好的設計能夠極大的減少代碼量和出 bug 的可能。 第二是擁有大量可重用的模塊和組件，能夠快速的實現交互
運行效率
運行效率是用戶體驗的關鍵，對于對效率要求極高的業務場景來說，這可能是選擇框架的第一標準
可維護性
前端開發中大多數在做的事情是：
1. 新業務加功能
2. 改版
3. 解決 bug
特別是在大公司的前端更是體會深刻，可能重來沒有做過新業務，都是在維護舊的代碼，填坑加埋坑。 如果業務代碼設計差，可閱讀性差，很難定位 bug。 特別是千奇百怪的 MVC 設計，大控制器，復雜的 Model ，想要定位出哪里出了問題真是一件 eggache 的事情。
體驗優化
體驗已經成了現代化前端開發的必談之物，所以出現了當頁面應用(SPA)，Instant Loading，Application Shell]，Progress webapp 這些名詞。
二、目前解決這些問題的技術方案
組件化：webComponent、polymer、x-tag、react、jQuery-plugin、angular-directive
模塊化：webpack、browserify、require.js、sea.js
開發效率：MVC(Backbone) < Flux(React) < MVVM(Angular.js、vue、ember.js)
運行效率：Backbone、React
可維護性：Flux、Redux
現代化的一些框架幾乎都包含組件化的考慮，不過在其他方面各有其優勢，關鍵點是在開發效率和運行效率之間的平衡
三、React 技術棧對上述問題的解決
注意我這里提的是 React 技術棧，并非題主說的 React，個人認為在描述 React 的時候應該是在講 React 生態體系，那對于上面說的難點痛點在 React 中一一對應的解決方案。
組件化：React 天生組件化，這是 React 的核心，除了能夠在團隊內部積累業務組件以外，也能找到眾多開源組件的實現
模塊化：基于 webpack 可以使用 Es6 或 CommonJs 的寫法實現模塊化代碼
開發效率：React 的代碼基本就是組件的組合，分而治之的方式讓代碼的可閱讀性很高，容易理解。 而且相比于 MVC 幾乎是去除了 Controller 的角色，只用關心一個 render 函數，不用關系視圖局部的修改。
運行效率：React 實現了 Virtual DOM ，相比于 MVVM 框架具有更優的效率
可維護性：React 基于 flux 或 redux 的架構設計，確定性的 store 很容易定位問題，無論是新增業務代碼還是查找業務 bug 都不再是難題
體驗：基于 React 可以很容易的實現 SPA （React-router）
題外話：大多數人說 React 技術棧的學習成本太高，其實我想說的是真沒有那么難。。。。真的，如果要學 React 但又苦于沒有系統的學習資源，那我就打個小廣告，最近在維護 LeanReact - 知乎專欄 ，會系統的講解 React 生態的知識，有興趣的朋友可以關注