標籤：

ReactJS 真的好嗎？

01-03

作為一個多年前端工程師，我認為ReactJS在真正開發大型複雜系統的時候並不好，首先最讓我詬病的一點就是，一個頁面的HTML模板被完全碎片化了，被分散到一個個的Component里，這樣的話，UI Designer和Dev根本沒有一個統一的視圖去協作。

或許ReactJS的本來思想是想讓Web頁面開發，變成類似以前Native Client的開發模式，用組件套組件的方式來繪製Web畫面，但是Web頁面的特性和Native Client還是有很大不同，Web開發有HTML模板這一層，而Native Client根本不要擔心這個東西，如何維護好界面模板的乾淨，統一，所見即所得是Web開發中很關鍵的一個環節，否則你會痛苦死，因為你要考慮多瀏覽器，多語言，Accessibility等等特性，而這些是讓UI Design Owner和Dev Owner能夠充分協作，各展所長的關鍵。

剛看到這個問題的時候就想回答，但前後幾個月才漸漸把思路組織好，昨天在平安那邊的技術分享上，講了這個主題，文本內容地址如下：

Web應用組件化的權衡 · Issue #22 · xufei/blog · GitHub

幻燈片如下：

http://xufei.github.io/slides/2015/components%20and%20templates.html

我的主要內容其實不是用來當做對「React真的好嗎」這個話題的回答，而是針對React或者其他框架所能夠帶給我們的組件化開發方式的一些思考，以及這些組件化開發方式可能會對我們的工程應用造成什麼樣的影響和改變，組件化是否必然好，在工程實踐中有怎樣的權衡。

我的觀點是，大面積的模板是有它的意義的，全組件化體系的工程負擔是比較重的，在Web應用領域全面組件化還是一個比較長期的路，而且Web體系當前自身的一些特性，也對全組件化有一些制約。

@Saviio 的答案中，引用了一個鏈接：還要多少年, 前端開發才能像客戶端開發那樣輕鬆？ - HTML5，這裡面有個回答是我的，但我要說的是 @Johnny Wu 當時的那個回答還要多少年, 前端開發才能像客戶端開發那樣輕鬆？ - Johnny Wu 的回答，這個回答非常好，組件化的實施也做得好，但我們需要認識到，他這個項目有其特殊性，目前存在的絕大部分Web應用並不是這個形態，這世界上大部分東西都不過是普通的東西，對這些東西來說，把各方面門檻提高太高並不一定是好事，正好比我們現在有能加工0.1毫米精度的機床，但在加工大部分產品的時候，只會使用1毫米精度的，因為絕大部分產品並不需要這樣的精度，提高不必要的精度可能會導致成本上升，對人員技能的要求也大幅提高。

我們看到ReactJS本身的定位還是一個相對大眾化的框架，它並不期望自己會成為小眾，一切組件化框架都不會期望自己成為小眾，那麼，為它們推出組件化的工程實施方案的時候，是不是需要存在兼顧高端和低端產品、人群的考慮？

所以，我提出，在大部分Web應用中，只適合使用「半組件化」，也就是基礎部分組件化，業務上層適當鬆散的方式，就是基於這些權衡。

在移動端，適合全組件化的產品比重會較高，因為方寸之地，組件樹一般不會特別複雜，工程代價不會很高，對生產力的提高比較明顯。

做項目做的異常痛苦中，抽空來答幾句。

逐條回：

首先最讓我詬病的一點就是，一個頁面的HTML模板被完全碎片化了，被分散到一個個的Component里，這樣的話，UI Designer和Dev根本沒有一個統一的視圖去協作。

組件(Component)的形式就好像我在後端碼一個個class文件，實現者通過定義功能以及性質來拆分視圖內不同的組件，保證其顆粒度，而Component文件本身的組織模式也是為了滿足近些年日益增高的前端工程化需求。

此外，業內也一直認為Component形式是前端在view層的一個恰當的抽象，這個概念並不是React才提出的，從早年的htc到jQuery plugin （我相信你一定用過bootstrap），然後到規範中的Web component，最後再到React。而且，如果說React 的Component是碎片，那我寫Angular時，定義了一個個Directive 是不是也是碎片？

UI Designer和Dev根本沒有一個統一的視圖去協作

我以為，UI Designer 和 Developer 協作的基礎是設計稿，而不是html，不是么？ 善用工程工具， 有些工具比如webpack，可以在區域網內起web server，你和設計師離著幾個工位，也能根據實現效果在IM上溝通，你覺得這樣的協作如何呢？

用組件套組件的方式來繪製Web畫面

HTML 本身就是 標籤嵌套標籤。組件套組件有何異議呢？

Web開發有HTML模板

模板的作用是什麼呢？是為了減輕前端直接通過構建DOM 字面量來形成View時的負擔， 然後我們再 clarify一次 React 是什麼？

官方的定義很明確，View in MV*

我沒見過誰在新項目的前端里用了React還要用像mustache這樣的模板的(除了三哥的外包，一個項目里我同時看見了ng/bootstrap/react，還有legacy 項目也除外，這部分更多的是妥協)，而React 的做到的早已超過了模板引擎。 這方面請移步這篇 有哪些好用的前端模板引擎？ - 尤雨溪的回答

如何維護好界面模板的乾淨，統一

React的存在恰恰是為了達到這個。

所見即所得是Web開發中很關鍵的一個環節

我想你一定不知道 React Hot Loader, see Dan Abramov"s talk on Hot Reloading with Time Travel. 前半段，請自備梯子。

然後最重要的：

現如今，大家開發前端的思路早已不是當年的 Web page，而是 Application，工程化的需求也比前些年提高的無數倍，去年我用grunt，後來用gulp，然後browserify來了，今年我用webpack，babel，工具的更換意味著開發體驗也是越來越好。(os:要是Atom能變成Visual studio那樣All in one IDE，那就感天動地了)

你提到

變成類似以前Native Client的開發模式

可在我看來，前端開發終於看到了這樣的模式進行開發的希望，一路走來，實屬不易。請再移步

還要多少年, 前端開發才能像客戶端開發那樣輕鬆？ - HTML5

以我看，React + Flux 得到了迅速的傳播，其中Flux的輪子更是每周都能長出一批。但當我們具化到原因，則是因為它們的組合以一個相當簡單的方式幫助FE們達到了冪等渲染——同樣的輸入即得到同樣的渲染，UI=f(state)。而客戶端編程歷來最麻煩的是什麼呢 —— 狀態遷移導致的視圖變化。藉此，FE大大減低了狀態的保存與管理的成本，此外我們還可以通過一定的手段，復現過去的動作。

dfguo 之前在teambition 的react 分享會上說："最早，我們做前端編輯器的doredo，寫了兩個禮拜。後來當我們決定用React重寫之後，這個功能我在去北京的高鐵上就搞定了"

至於這方面的演示Demo，同樣，請看上文貼出的Dan Abramov"s talk on Hot Reloading with Time Travel. 視頻的後半段。

我並沒有想吹捧，Flux剛出來的時候我也是存有質疑看了很久，但基於React下的UI開發，確實提高了生產效率。

另外JSX不是HTML，JSX不是HTML，JSX不是HTML。 重要的事說.....

組件化開發終歸是個好事，前提是你們的前端Leader，還有設計師團隊能想明白這件事兒……

Angular2 也是以組件為核心的，和React異曲同工，代表業界一個大的趨勢，相信也會吸取React的虛擬DOM的優點的……

題主可以先學習一下Angular2，我覺得比React要清楚合理的多，當然React只是一個View層的方案，具體使用肯定少不了M和V層的配合，單是用React是不容易做好單頁面應用的。

組件化是前端大規模工程化的基礎，沒有組件，則無法高效的重用代碼，組件幫助開發者把不關心的代碼做成黑盒，你只需要關注你關心的代碼就好，不需要擔心你的改動會影響其它代碼/組件的運行，同時組件化也符合面向對象的思想，模板則是原始的HTML+CSS和弱OO語言JS之間妥協出來的產物，模板只是在做DOM層面的組件化，一些事件和邏輯任然需要額外的JS代碼來維護，這個時候你會發現，其實可以把DOM和JS邏輯封裝在一個組件里就好啦。至於你說的組件碎片化，那是因為reactjs不像其他native組件化圖形界面框架一樣給出了一整套基礎解決方案，像最早的c#,flex都是官方給出了一套基礎控制項庫，開發者無須再造輪子，直接通過繼承來擴展各種基礎控制項，而react只是告訴了你造輪子的方法，輪子還得每個人按照他給的方法和工具還得再造一遍，碎片化不可避免。另外，html本身就是組件化，像Input標籤，form標籤等都屬於官方標準的組件，各大瀏覽器廠家來實現，只是因為html原生的組件太底層，標準制訂的又太慢，導致每個前端都在造自己的輪子，嚴重拖累開發效率和工程化。既然官方原生的組件搞不出來，那就各大廠家自己搞，react，angular等都在組件化上做出了探索，但react的探索做的最徹底，不僅從html中抽象出了組件，甚至抽象出的組件還能平台無關，給混亂的前端界帶來了一絲秩序以及無限的想像空間。

上面的同學，幾乎都在闡述 組件化的想法，都很為詳細。我說個額外的。

對於React，不要僅僅因為它 實現組件化 的組織方式前沿 而去使用，能不能花點時間考慮一下它的核心 - 虛擬DOM 對項目的可用性。

更多地去考慮引入這個框架能解決什麼痛點，引入這個也有什麼痛點，兩者之間去取捨。

現在用 aralejs（本地封裝了大量的組件）開發，看完 react 後，發現很多痛點 react 都給我解決了。

至於，組件套組件，不知道題主所在的團隊實際情況是什麼樣的。

我現在的團隊，前端 10 人左右，並行的 Web 項目 5+。

為了提高效率，裡面有很多通用的模塊（比如數據表格、表單、日曆）需要復用。

這些模塊之間，可能互相包含互相依賴。

為了避免重複工作以及提高效率，我們能想到的最好辦法，就是通過組件來實現復用。

因為，世界就是模塊化的。

所以，組件套組件那是極好的。

多年來，web技術的進步是很小的

http, 協議是低效的

html 是基於啰嗦的xml，自然啰嗦

js 語言很另類

css 是一種硬編碼

無論什麼框架，上面這些都是基礎，自從nodejs的出現，上面這些問題被web開發者們關注了，於是對於前端的各種改造就沒停止過，ts,cs,es6, less, sass, jade ...還在繼續

也許，nodejs的最大價值在於，它讓js走出瀏覽器，這意味著在其它領域一定會形成對比，對比這下，這個多年都不思進取的語言捉襟見肘，引發了改進潮

有點扯遠，說說樓主的問題，react 所謂的全是組件，組件套組件，這個windows編程的概念是一樣的，都是窗口，窗口套窗口，這個概念微軟早就有了，我能說所謂的組件是一種倒退嗎

GUI編程，做過的人都知道，比做網頁要難的多，所以GUI一般庫都會有 html 組件，因為很複雜的任務用網頁實現會變得很簡單，自從QT有了 QML， 就更像網頁了，如果說做網頁非要模仿GUI，我想你走遠了

網頁模仿GUI，理由是感覺很高端，從此脫離草根

GUI模仿網頁，理由是讓問題變得更簡單，從此讓生活變得更輕鬆

So 我的觀點是，react 或類似的框架 是把簡單問題複雜化，已經走遠

關於React是否真的好用，我覺得大家可以讀讀這篇文章《前端開發框架簡介:angular和react 》。

文中提到：

為什麼用react

雖然目前react非常之火爆，但說實話，我也不知道在現在環境中用react有什麼意義。
在使用angularjs開發幾個項目之後，如果需要轉向react，只有以下幾點可能會吸引我：

  1. 足夠好的性能
  2. 跨平台開發的統一體驗。這個還得等react-android出來後才知道。
  3. 兼容其他js庫，在現有項目中就可以使用

而對於angularjs，我認為目前angularjs已經足夠好用了，除了以下幾個顯著的問題：

  1. 性能問題，目前angularjs在移動端的性能確實不夠，因為它實在太大了。這個問題是最致命的。
  2. 只能在angular的框架下開發，第三方庫要兼容angular都需要做一些工作。

對於angularjs其他所謂的缺點，其實大多可以解決，只是難易程度不同，例如SEO/構建等都可以解決。
上手難易程度來說，angularjs確實比react難很多，但這和一個工具是否好用沒有關係，例如正則。

網上看到大家都在鼓吹react如何如何，又有很多人拋棄了angular投向react的懷抱。說實話有點吹的太過了。
react只是讓組件式開發和復用更加簡單好用，外加逆天的性能，僅此而已。

閱讀更多：

前端開發框架簡介:angular和react - 騰訊雲技術社區

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

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

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

多謝回答 ：），我並不想說那個技術一定比另外一個技術更好，而是從實際出發，結合我們目前的產品特點來描述ReactJS之於我們並不是十分合適：

首先，我們要把一個10年前的老SAAS在線Service用全新的技術進行改造，而這個產品是面向全球的，在這個行業內，一直佔領50%+的市場份額，支持15個國家的語言，全球有7大數據中心在後台支撐它的運行，業務邏輯和頁面複雜度（單頁面頁面元素非常多，元素之間的交互卻不是很頻繁）非常高，並發訪問量很大，具體不是很清楚，我不負責Cloud Service Support，大約也在百萬級並發，這次改造力求要用最快，最穩定的方式平行遷移老Features到新的平台，至少在遷移過程中，新老平台要並行在線很長一段時間（1~2,3年），而我們的工作是選擇一個適合的前端框架（後端有別的Team負責）來縮短這個周期。

通過對比，我發現：

1， React.js里所謂的「頁面組件」，並不是指一個checkbox，或一個input這樣細粒度的組件，可以理解為對一個「功能單一的一個頁面區域」的封裝，粒度更大。雖然checkbox等也需要封裝住成組件，但那是粒度更細Controls，和React.js的組件概念不是一個級別。

2， 在我看來，官方的React.js例子是個極端的例子，整個單頁面應用，全部用上述「頁面組件」套裝起來（換句話說，全部用JS渲染，當然這個頁面還比較簡單），所謂的layout頁面（index.html）是空的，也就是調用一句JS去render 「root頁面組件」而已；

這和AngularJS的directive雖然類似，但是在用法上卻又本質的不同：

1）使用AngularJS，你仍然保有一個完整的頁面模板（視圖），要不要用directive是個可選項，而且用AngularJS，也不會傻到把一個單頁App應用完全用directive套裝的方式來構建。

2）我沒用過React.js，看官方例子，貌似推薦全部用組件套裝的方式來組織一個頁面（應用）。繼而，你會發現，「我們所認知的頁面模板」被碎片化了，HTML片段（或是JSX）被分散在一個個JS代碼段里（「頁面組件」被封裝成一個個JS類），個人認為這是個不好的體驗，比如：當頁面出現一個layout問題的時候，往往需要調整dom節點以及上下文節點（你懂的）的Style，甚至需要重新調整整個Dom結構，如果用AngularJS之類的技術來做，我在Firebug里看到Dom結構和HTML模板幾乎是一致的，我可以很簡單的去調整HTML模板來達到目的，有時候你可能還需要在不同的瀏覽器，不同版本下去查看頁面是否OK，這是一個繁瑣和吃力不討好的過程，有個完整的HTML模板去調整，總是比較好；但反觀React.js，如果我們的HTML片段分散在好幾個JS文件里，我還得一個個找到它們，然後再逐個調整每個JS里render()方法里渲染出的那段JSX，好吧，我還得動腦子想像一下它被渲染成HTML是啥樣子，然後再做適當的調整，如果拆分的JS組件過細，我的工作量就巨大了。大概就這個意思，開發看起來很爽，維護起來頭大，雖然模塊劃分明確，但是我們同樣面臨著一個問題，改怎麼劃分它的顆粒度？

我之前做過一個項目，使用Dojo Toolkit，最後的結果是一個後台管理應用的每個可視頁面就用一個自定義的Dojo Widget來實現（組件粒度更大，一個頁面一個Widget組件），然後把這些Dojo Widget組合聯動起來，就變成了一個大的App應用（完全JS渲染，雖然Dojo有垃圾回收機制，但瀏覽器一直無刷新，悲劇了，運行一段時間後，瀏覽器內存泄露，Crash掉，後來改造，加routing，定時刷新以釋放內容 etc.，不說了，說多了都是淚......）。

回到使用React.js劃分顆粒度的問題……多大粒度的頁面 or section 可以被封裝成一個「頁面組件」，過大，則失去其重用性（天呢，這是react.js的核心思想啊）；過小，則面臨著模板碎片化，難以維護的風險，參考上文。

我們不能要求所有的開發人員都在Same Level！

3， 最後關於示例中用「反向數據流」來實現「頁面互動」（或者說數據雙向綁定）看起來過於複雜，難以理解，對比AngularJS的數據雙向綁定，我覺得學習曲線要陡。

當然，我並不是說AngularJS就一定比React.js要好，我一直對AngularJS的雙向數據綁定持保留意見，它的性能實在不夠好。

以上只是本人拙見，我也並不想重複造輪子，自己整個什麼框架出來來顯示自己多牛逼，那是傻子的行為，我只希望利用現有成熟而又合適的框架來快速實現業務目標，比較一個產品的好壞，技術並不是最重要的。

題主的感覺是對的。 組件方案技術上的方便宜用，與人力上能scalable是相互衝突的。一個組件包含了 JS、HTML 和 CSS，那麼他的擴展修改就不是那麼容易的，特別是對於只懂 HTML 和 CSS 的初階開發者或者是設計師、懂一點點編程的營銷人員等等。

所以在雲信這樣的諮詢公司，我選用了 ractive。

我覺得有必要評價一下。我寫了很多的網路層、傳輸層的解析器和編碼器，也寫了很多的應用層的服務，包括渲染的一些東西。使用了 mustache 風格的模板引擎，ES 6 字元串模板，Reactjs 的 JSX 以及 TypeScript 的 TSX （JSX+TypeScript），綜合來講，我覺得 React.js 對於菜鳥和 Java 程序員是有用處的，但是對於一個專業的程序員，則是沒有「大」價值的。我這裡評價的點是「大」，React.js 以及 Vue Angular 之類的應該是有價值的，但是這些價值實際上則是「沒有意義的」，至少不夠「大」。

所謂，MVVM，數據雙向綁定，不過是數據變動導致界面再次渲染的代碼量的減少。但是，少，不表示就是好的。事實上，使用 TypeScript 語言和 ECMAScript 2015 的字元串模板，完全不再需要任何的模板引擎和 MVVM 框架。

如果你用過 nodejs 的 express 框架，應該知道有所謂 「路由」的寫法。即你所有的工作是編寫一個一個「路由」的文件，然後把他們串聯起來。事實上，瀏覽器的 JS 正是這種邏輯。你所做的事情只有為 DOM 元素編寫一個一個「路由」（「事件」）而已。

關於字元串模板代替 MVVM，可以舉例。使用 TypeScript 編寫 C-style 的程序，用 table 和狀態機的方式組織你的代碼，要比面向對象清晰、簡單、容易擴展：

/*

程序中的用戶界面如下：

[ input age to filt users ... ]

* XiaoMing 16
* Lili 61
* Tom 36

*/

// 只需要一個 jQuery 來簡化 DOM 的操作
// 使用 webpack 或者 browserify 的打包來提供 module 的支持
import * as JQuery from "jquery"

type User = { // 定義 User 這個數據項
name: string
age: number
}

function filtByName(users: Array&, age: number): Array& {
// 通過 age 過濾用戶，只需要等於 age 的用戶
var result: Array& = []
for (var user of users) {
if (user.age === age) {
result.push(user)
}
}
return result
}

function renderUserItem(user: User): string {
// 渲染一個列表項
return `
&${user.name} ${user.age}& `
}

function renderUserItems(users: Array&): string {
// 渲染一個列表組
var items = []
for (var user of users) {
items.push(renderUserItem(user))
}
return `${items.join("
")}`
}

JQuery(document).on("change", "#user input", function (e) {
// 輸入 age，過濾，重新渲染
var list = JQuery("#user ul")
var age = parseInt(JQuery(this).val())
listhtml(renderUserItems(filtByName(users, age)))
})

JQuery(document).on("click", "#user li", function (e) {
// 點擊一個列表項，改變其激活狀態
var items = JQuery("#user li")
var activeItem = JQuery(this)
items.removeClass("active")
activeItem.addClass("active")
})

進一步，你可以抽象 ``JQuery(document).on("change", "#user input"`` 和 ``JQuery(document).on("click", "#user li"``。比如說強制每個元素使用一個 data-path 來作為路徑選擇器：

var app = new MyDefineApp()

app.change("/user/input", function () {
var list = app.find("/user/ul")
var age = parseInt(this.val())
list.html(renderUserItems(filtByName(users, age)))
})

app.click("/user/li", function () {
var items = app.find("/user/li")
items.removeClass("active")
this.addClass("active")
})

東西出來都有其意義，自己上手做幾個項目，實踐出真知，不好用就別用了....我覺得目前題主項目產品中可能沒有什麼痛點

組件化思想挺好。但是 jsx 就是反人類設計啊，js,html混成一坨。 如果能view ，js 分開就好了。比如對於一個組件，.html 是它的UI部分(html+css)， .js 是 邏輯部分（js）， 這才是正確合理的。話說我們為啥啊不寫一個。

React把HTML、JS和CSS統一到一個組件里，這是趨勢，React其實實現了Web Component的功能，如果Web Component這個標準趨勢不利於大型軟體開發，那我們就可以懷疑React是不是適合大型應用開發。

我個人觀點：React當然能。

------原回答分割線

一說到React，很多人想到的是「組件化」，組件化當然是React的一個優勢，但也許是最不重要的一個優勢，因為組件化並不是一個React特有的東西。。

jQuery時代，一個jQuery模塊也可以封裝一個功能，也可以提供介面給外部調用，那你說這個jQuery有沒有實現模塊化？當然實現了！所以說，模塊化並不是React特有的優勢。

React最大的優勢，是用declarative programming的思想來實現模塊化。

所謂declarative programming，是不是可以翻譯成「聲明式編程」，本質就是說，讓程序員只要描述「我想要什麼樣的東西」，而不要糾結於「怎樣做才能實現這樣的東西」。

和declarative programming相對應的是imperative programming，imperative programming關注的就是「怎樣做才能實現這樣的東西」，jQuery就是典型，你看，在jQuery中，總是選中某些DOM元素，然後操作它們的屬性或者添加一個事件處理函數，程序員必須操心所有的DOM操作，而且，對於這個過程是是重複了又重複。

我們打個比方，每個年末互聯網公司都會開年會，不同部門不同組在年會上要貢獻節目，節目需要道具，於是要採購道具。一種採購方法是這樣，HR通知各組去採購道具，每個組各自上淘寶天貓上去找，和店家討價還價，商量細節，買完道具任務結束；還有一種方法，HR問各組需要什麼道具，各組告訴HR需要道具的清單，然後HR統一到淘寶天貓上去採購，HR負責討價還價，HR負責處理細節，最後搞定所有道具。

你覺得哪種方法更好呢？

我想，毫無疑問第二種方法更好，因為這樣免去了各組之間的重複討價還價勞動，而讓各組只專註于思考需要什麼道具如何編排節目。

第一種方法，就是imperative programming，第二種方法，就是declarative programming，也就是Raact的做法。

（地鐵上寫的，手機寫字比較費勁，先發布回頭再更新）

瀉藥

我這種沒用過的又能說出來個啥

只能抖機靈坐等被摺疊

所以你也就看看得了

別往心裡去

這種玩意年年會來新的

一年一個樣

或許是包裝成新概念

或許是有著大公司光環

等等

反正流行起來了

大家（起碼是大部分人）不管是真說好

還是（小白）跟風說好也罷

現實輿論環境就是你不能說它不好

否則是政治不正確

等他過時了再說不好也不遲

不管怎樣

對外統一口徑就是：

「好的不能再好了」

哪怕你心理罵傻逼

實際上老子打死也不用的架勢

口不能松

鬆了就是異類白痴

得罪全社區

不錯的，勝過jade

看了Saviio君的回答覺得受益匪淺……

其實仔細看了一下題主的描述，還是覺得題主的前端思維還停留在只寫頁面的前端時代……雖然用了一大堆高大上的辭彙……

首先是現代的前端開發已經不是僅僅去寫界面，而是完整的應用開發……雖然React只負責view層……

想補充一些自己的看法。

不知道題主用沒用過backbone之類的mv*框架或者純自己寫也一樣。現在的前端經常要涉及因為狀態的改變而進行視圖的改變，這時候往往會有比較複雜的DOM操作。而這是我覺得React最棒的地方，它讓你從這種麻煩的工作中解放出來，專註於應用中本身的邏輯。

本來無論是工具和框架，大多數的都是用來提升開發體驗的。這一點上來說，React算得上一個好框架。

然後關於題主對於視圖開發效率的擔心，如saviio君所說，社區已經有很多非常高效的工作流，比如react-hot-loader，react-hot-loader和react-hot-loader。最近dan大神的新品Redux也可以看看。

最後，無論什麼流行的東西肯定會有大批的跟風者，不過也至少是有理由的。React一開始出現的時候也受到了很多非議。所以我覺得想用就了解下，覺得很合適就用唄……

最後的最後，ES6大法好！！

這個框架的設計有facebook自己的人力資源配置的大背景。有好些美國的公司美工只畫圖不寫代碼，剩下的由前端或者全棧應用工程師完成html、css、javascript甚至應用層的邏輯。這種情況下把html、css、javascript捆綁在一起就沒什麼好奇怪的了。這三樣東西裡面javascript可以干剩下兩樣東西的工作，而且ES6大法好，據對是勢不可擋，自然用一套系統能幹甚至干好的的事情就不應該用三套系統干。

先說結論：

1 從功能開發角度說，React的思路很好。

2 從頁面設計角度說，傳統的HTML+CSS以及同樣思路的模板更好。

3 React好不好，團隊中不同的角色會有不同的結論。

4 個人更傾向於考慮在什麼情況下適用，什麼情況下不適用，以及如何改進。

模板和React系列是兩種思路：

一種是從界面入手，嵌入功能；

一種是從功能入手，生成界面。

考慮到Facebook推崇全棧編程，那麼在各種方案不相上下的情況下，統一開發思路是比較好的選擇，於是有了React和React Native。

@Saviio 的這句話一語中的：大家開發前端的思路早已不是當年的 Web page，而是 Application。

但是，個人並不很喜歡這種純後端的開發方式，剛學前端的時候，我寫的代碼基本也是js控制一切，覺得寫CSS很彆扭，但是後來真正學CSS的時候，又覺得這麼寫才合理，不應該都寫到js里。尤其是涉及到布局和頁面風格的問題，單純用js實現很不直觀。

有人說HTML和CSS這種寫法如何反工程化，只有js實現才好，但是有沒有想過：CSS和配置文件是一個思路的呀，能接受得了配置文件，就不能接受CSS么？安卓的界面可是用XML配置的，和HTML難道不像？

另外還有一點，大多數公司不是Facebook，沒有那麼多全棧高手。團隊中擅長寫業務的，未必擅長頁面布局；擅長頁面布局的，未必擅長寫業務。這樣在團隊中必定會有分工，其中會有些人著重實現炫酷的頁面效果，而React顯然對這種分工不友好。

我們更多的時候，更應該思考的是平衡和最優組合：

什麼情況下應該後台渲染，什麼情況下應該前台渲染。

什麼情況下應該用html+css控制頁面，什麼情況下應該用js控制頁面。

如果讓我選擇的話，我更傾向於組件級別的模板。

個人希望有個htmlx、cssx之類的技術出現，直接在html和css里寫React組件，最後再編譯就好。

推薦閱讀：

※相比 React 全家桶，選擇 Vue2 有何優劣？
※為什麼都說富文本編輯器是天坑？
※怎樣可以很好地保證網頁的瀏覽器兼容性？
※如何評價Facebook推出的flow.js？
※jQuery創始人知道function test(){}這樣定義函數不好嗎？

TAG:前端開發 | JavaScript | React |