React解決了前端開發中的哪些痛點？

01-21

看到很多文章中總提到React解決了前端開發中的很多痛點，但都沒有說明具體解決了哪些痛點，各位大神來總結總結，同時React又引出了哪些新的問題？

隔離了 DOM 操作，但&向前兼容&（抱歉，此處應為向後兼容） HTML tag，入門成本很低
解決了數據綁定的問題（當然別的主流的框架也一樣
組件化
vdom 使得上層代碼平台中立化
只做 view，可以結合多種數據流管理實踐（flux 並不是必須的

React 可以堅持很久，或者說這種 vdom 層的思想可以堅持很久，甚至各大主流 mvvm 框架都會慢慢有類似的特性；但 flux/redux 寫著麻煩，潛在競爭對手強大，就不一定能堅持很久了。

看了大部分回答過後，感覺總有些差強人意，要麼抹黑，要麼不理解，下面我分一下邏輯來詳述一下我對這個問題的見解。

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 生態的知識，有興趣的朋友可以關注

大程序狀態變遷多，以前都是每個狀態手動維護，維護的是該狀態變化後DOM應如何相應變化，要小心翼翼，因為DOM操作比較昂貴，所以能少操作就少操作，React引入了Virtual DOM，讓你不用小心翼翼，它替你搞定DOM操作，並且保證效率，這樣就解放了大程序開發的大部分時間（複雜程序維護DOM操作很花時間）。

開發和維護具有複雜交互的界面，變得容易。複雜交互是指，點一下某處，其他好幾處都要跟著變；在條件A下如何顯示，條件B下如何顯示，條件C下如何顯示，而條件A、B、C又要根據用戶的交互行為確定，等等。

如果是做側重於展示，而不是交互的web應用，react是不會解決什麼痛點的。

以前寫交互代碼，這裡插一個node，那裡刪一個node，都要自己手工來，現在不需要了。表達交互更容易之後，頁面就可以根據用戶的行為，做更精準或者有趣或者快速或者其他讓應用顯得更智能的展示。如果交互做起來成本高，可能開發者想都懶得想。

當然複雜交互用其他一些框架也可以做得很好，本來都是同世代的東西，相比起來沒那麼多亮點很正常。

JSX不是react必須要用的，不用JSX直接純js寫結構一樣可行。另外單向數據流也很重要，狀態怎麼變可以一目了然，定位bug不要太容易。

--------------- 媽媽說講故事贊多 --------------

北地有一村，名曰歪家莊。

此地夏日多雨，冬季結冰。

村莊四周，被河包圍。向前渡河可到對端來到外界，河名「前端」。

因冬夏天氣所擾，村民多外出務工以貼家用。

歪家村有一戶，兄名沛；弟名愛沛。

二人相依為命，夏季時兄長渡河而出，夏末歸家；冬季時幼弟外出，冬末歸家。

一日冬末，幼弟歸家，帶回一套雪具寒服及冰刀，言及此物乃遇仙人所賜，平渡前端極為爽利。

兄問：「此何物？」

弟答：「此仙人所賜，初始尚不習慣，後來熟悉後再無摔倒，行進如風，只比飛翔稍緩。仙人賜名曰徐飛，誠不我欺。」

兄大驚：「竟如此？如你所說竟似比我等所受神物更加便利？待來日為兄一試。」

轉眼夏至，雨紛飛。

兄厚著寒服，至河邊，穿冰刀入水而溺，遂被「神物」救起。

兄蘇醒時，乃平躺一舟之上。舟有烏篷可避雨，舟身有題字：「游於此地去贅衣，雨絲紛飛似天低，溪水四聚沖刷堤，鑄舟得名游雨溪。」

此神物乃沛外渡前端常用之物，此前夏日渡水皆要裸身游泳而過，有此神物後可悠哉悠哉，再無濕身入水煩惱。

兄怒斥仙物不利，擲於水中，曰：「此廢物也，用之徒增煩惱，甚不如赤身過水。」

------------------ 分割線 -------------------

為什麼React一出來，總有人覺得他沒有解決前端的痛點？

其實React真正只幹了兩件事：

1、組件化

2、數據流向

其他的一切，都是副產品，不算解決痛點的急所。

日漸沉重的邏輯、複雜的交互、各種狀態變化，被分解的清楚乾淨。

君不見一個組件化，讓WebApp的開發者得以分治、復用，界面如一個樹形一目了然。

一個 UI=F(state)，讓開發者喜極而涕，再不生煩惱。

為啥搞WebPage的大多沒有爽利的感覺？

因為本來就沒有重邏輯和複雜交互，更有的直接就是展示型WebPage。

本來一個完整乾淨的界面被React切的支離破碎，看不到一絲的優點。

為什麼覺得他是個廢物？因為他要解決的痛點，你根本就不痛。

按照以往的前端最佳實踐，假設一個人寫一個中等複雜度頁面要5天，從樣式到業務js邏輯一點點碼出來大家是不是都很熟悉？如果這個時候老闆說給你10個人你給我半天就上線，這個時候你怎麼辦？一個頁面切成十份，大家開發互不影響，也沒時間互相溝通去了解對方是怎麼寫的，這個時候大家想到了組件化，彼此組件互為黑盒，減少溝通成本，N個人可以並行開發，效率大大提高。稍微有點經驗的碼農都知道，這種概念在native上在desktop上早就被玩爛了，後來的各種RIA解決方案也都又將之前說的概念實踐了一遍，現在JS也來再玩一遍，實在沒啥新鮮感，最大的不同就是各自的runtime不一樣，畢竟瀏覽器運行時的普及率實在太高。由於web標準的非封閉性，導致長期看來其普及率大跌的可能性還是很低的。喏，現在fb也跟當年的java，adobe的air一樣，到處寫runtime，使得一份代碼到處跑，雖然fb還做不到像AIR和java那樣跨平台api的高度統一，但至少讓大家看到了方向和希望，所以滿世界的前端都知道react大法好，接下來fb或者其它什麼大拿應該會按照套路出牌，每天都會誕生各種基於react的組件framework，各種runtime。前端同學也終於不用忍受稀爛的瀏覽器運行時，想想還有點小激動呢。

1.diff node配合flux讓應用的狀態管理成本和複雜度大幅度下降這個是解決的最核心痛點

2.學習曲線比較平滑相比ng backbone而言

3.react native相較於hybrid方案的性能提升

組件化這個事情現在的主流框架都有只是方案各異所以算不上react的優勢

但是第一條真的太贊

自從用了react, 覺得產品經理沒那麼煩人了。

組件化是目前所有框架類庫中做得最好的。React能將所有數據都對應頁面的一個節點（當然false, undefined, null, true會被忽略掉，或變成一個注釋節點做佔位符）。編寫組件非常簡單，這依賴於其強大的JSX DSL。

生命周期非常強大，並且足夠用。

API比較少，只有10多個方法與屬性，因此易於上手。新人可能卡在搭建環境上，但一般公司肯定有高手將腳手架早早搞好，GITHUB上也有大量腳手架可選用。

性能非常好，在React16 中會更加好。

生態圈活躍，光是CSS處理方案就300多個。好用的UI庫太多了，挑花眼。高手雲集，每個解決方案與新點不斷湧現。

在維護大項目中有很大的優勢。

在做手機上，使用RN非常方案，性能也超出你預期。

美中不足的是：

由於沒有雙向綁定，做表單非常麻煩。官方推薦的狀態庫非常難用，redux什麼也用大量中間件與樣板代碼來搞一些非同步。這裡就強烈推薦用mobx了。

用React 寫業務代碼也比JQ可能多許多，不那麼直接，如果有人在React忍不住在用DOM操作，會坑死許多同事。

由於封裝程度太高了，用了React後，許多DOM底層的知識都用不上，也記不起。CSS就更不在話下，要求直接在JS里寫CSS，破了我們長年積攢下來的經驗，許多人都有反感與抵觸。

體積很大，大得讓你頭痛，這時建議使用迷你React框架，如anujs與preact。

RubyLouvre/anu

anujs主要勝在與React的兼容性上，能支持React大多數UI庫與工具，能直接替換已經完工的項目，與編寫依賴於大型UI庫的前後端工程。

developit/preact

preact主要勝在性能（其他用了虛擬DOM，anujs、preact都在60幀左右）,許多UI庫可能支持不了，但preact有自己的一些UI庫，都是比較迷你的。在做一些小項目有優勢。

React 除了React Native還有React Art(做圖形)，React VR，可以讓你延伸到更多平台，而不單是做網頁。這對開拓我們的眼界有很大幫助。

證明了前端摩爾定律 _(:_」∠)_

1、組件化，更加容易的綁定事件行為，動態更新特定的dom

2、在一定程度上統一了前端開發，雖然移動端和瀏覽器端用的不是一套SDK，但橫向移植成本也不是很高

3、良心的配套了React-native，藉助動態語言的天性，讓移動端實現插件式解決方案更加優雅

4、做前端的看上去不那麼廉價了

性能，對於react、angular、jQuery，我們在pc和mobile端都做過對比測試，react是唯一的update時能優於create的框架，vdom的作用毋庸置疑。甚至將性能最差的angular結合react，性能也能獲得提升。

至於jsx、組件化、flux之類，應該是前端開發的趨勢性引導，沒有什麼實質性的作用。

想要打動架構師或者研發的頭頭們，性能這一條足以。

react里最有價值的是virtualdom

可惜這個也不是react發明的早有類似的實踐

react也沒出眾的性能

不過把個js庫搞成比js框架還大的 react獨一份

搞成平台就更樂了

react native？別逗了這是做移動玩具應用用的

精品移動app 規規矩矩java objectivec

jsx真的是坨屎只有facebook要下崗的php程序員才會搞出這種東西

React顛覆了以往前端開發的最佳實踐，但它究竟解決了前端開發哪些痛點這個問題，Google了一番，沒有找到比較好的回答，先在這裡拋磚引玉。

1、複雜的狀態更新；

2、組件化開發：適可而止，不可過度組件化；

3、提升了開發效率；

4、虛擬DOM解決了以往大量操作DOM帶來的性能問題；

5、diff演算法：樹形結構不同直接移除再新增節點，不去徒勞的進行比較，簡單粗暴高效。

雖然React帶來的優點顯而易見，但也存在很多問題，比如：

1、jsx混搭js、html，初次看到真的是丑到哭；

2、React入門簡單進階難：React＋Redux＋webpack＋ES6＋react-router 等一大堆名詞嚇死初學者；

3、React真的是很好的解決方案嗎，它能堅持多久？

提一點很重要的，react的項目後期維護起來方便。

如果在用jquery，頁面交互多了，其中一個元素的狀態變了，根本不知道是哪裡觸發這個改變的。只能在js文件里去搜全部操作這個元素的地方。然後一一驗證。

react就沒有這個問題，元素的狀態是state的函數，即UI=F(state);只需查找改變state的地方，就能清晰的知道是哪步操作改變了state,進而重新渲染UI.控制了數據，就控制了UI.

本質上來講，react數據流,只有數據（state）變了，才會改變UI.相比於單個操作dom,數據流要清晰多了。

Why React? | React 說的很明白

"We built React to solve one problem: building large applications with data that changes over time."

分頁阅读： 1 2