如何看待 React is a tax Facebook levies on startup 的說法？
ReactJS is a tax Facebook levies on startup web development.
並不是太贊同@尤雨溪react慢熱的說法。首先react本身的理解成本是所有view層解決方案里最低的，給什麼數據渲染什麼UI，就一個函數這麼簡單。理解了JSX的編譯後所有東西都是純js的，沒有黑魔法。絕大多數情況下沒有框架做了你卻不知道，或者你需要問框架才知道怎麼做的事。
相比之下，多數mvvm都有自己的綁定語法，作用域和事件機制，這些都是額外的學習成本
那麼react的痛點在哪兒呢？在於它本身作為純view的方案，要搭建項目需要自己整合大量的第三方庫，這個過程中被坑的概率很大，即使是老手被版本升級啥的坑到也是常有的事。我們經常說全家桶，其實真要有全家桶那樣開蓋即食，倒也是幸事了。
社區上有不少starter kit類的模版庫，但一方面並不能完全滿足個人需要，另一方面隨著這兩年的高速發展和迭代，很多庫的版本和用法都有不小的變化，很多模版庫其實是過時的，這些過時的庫和文章不僅沒有幫助，甚至還會造成誤導，從而加重學習過程中的心智負擔。最近的create-react-app也僅僅減小入門成本而已，和真實項目不搭邊
既然有以上痛點，為什麼我不贊成說react慢熱呢？
因為在多數項目中，以上的工作都可以由一兩個有經驗或者肯折騰的人搞定，對團隊的影響非常小，甚至得益於react較低的理解成本，新人上手產出的速度是非常快的
而新一代的mvvm比如vue，優點其實在於設計友好，在我看來道理不夠直觀的黑魔法封裝對後端或者設計而言是莫大的便利，拿到html稍微查下文檔就能做出可用的頁面。而得益於優良輕量的設計，這些頁面也並不容易成為維護負擔
個人而言我還是更喜歡react這樣像函數一樣"講道理"的東西。但也不會反感vue這樣面向不同習慣的方案，嘛，至少在"簡潔並講道理"方面比ng好多了聲明下，每次回答 React 相關的問題，即使我答案里一個字都沒提到 Vue，也總會有些人不分場合來糾結 Vue 哪裡不如 React，評論里的不會再回了，愛用 React 您就繼續用唄，沒人逼你用 Vue
ˉ\_(ツ)_/ˉ
---
並不完全認同這篇文章，用英文來說這是一篇標準的 rant，但是原文裡面很重要的一點就是 startup 這個場景。
樓下有人說，咱們是工程師啊，你得有追求啊，你得寫正確、可維護、可靠、可復用的代碼啊！道理我都懂，可是你有沒有這個時間去做這樣的事是個問題。
Facebook 的工程師，工資福利待遇好，公司股價蒸蒸日上，人又多，當然可以（也必須）精雕細作。很多基層工程師可能一個人就只負責幾個組件，萬一走人了還要人來接攤，確保正確性和可維護性自然是最優先事項。
換成那些兩三個人的 startup，很多創始人可能原本就不是搞前端的，為了做個 MVP 不得不擼著袖子現學現賣，這種時候早一天出 demo，早一天有用戶，早一天融到錢才是關鍵，誰來管你代碼有多正確、可靠、可維護？當然不是說就一點也不管這些了，但是這時候這些東西是有代價的：在早期 startup 這個場景限定下，這是一個 trade-off 而不是 no-brainer。
我個人認為 React 棧的生產力曲線是慢熱的，在到達高生產力之前有一段相當長的低谷，除非你有老司機帶路。招到靠譜的老司機這種事情可遇不可求，在招不到的情況下選擇 React 確實是有一定風險的。為什麼這麼說呢？在完全新入坑的情況下，你面臨兩個選擇：1. 一開始就試圖吃下整個棧，研究各種 boilerplate，篩選出合適的部件，並且把它們組合起來。2. 從最基本的 React 本身用起，遇到什麼問題再去找對應方案。但不管走哪條路線，都不是很輕鬆的事情，需要相當長的一段時間去適應、理解、磨合。這個低谷期對於一些 startup 來說可能就是一個致命的問題，也就是節奏不合拍。很多已經越過低谷、並且不理解 startup 初期那種節奏的人，自然會站著說話不腰疼地強調一旦你精通了以後這個棧是多麼多麼好，但這就像『何不食肉糜』- 對於一個 startup 來說，如果你活不到那一天，這些好處都是白搭。
什麼產品都有其適用人群，一款想要能滿足所有需求的產品絕對是個爛產品。
所以，抑制生產力這個說法是存在的，存在於特定場景。如果你的應用達不到一定的規模，框架給你的條條框框比你得到的便利更多，這是很正常的事情。殺雞用了牛刀，胳膊不酸才怪呢。
但是為什麼那麼多人追捧這些框架？在我看來，這都是過度思考未來。每個產品的設計者都想著以後自己的產品一定會越來越複雜的，所以一定要把基礎打好，一定要設計出一個能支撐龐大體系的架構！
所以，抑制生產力的不是這些框架，而是你的思維。總想著未來你的網站一定會成為Facebook那樣的網站，所以現在總是追求Facebook級別的架構，總是追求一步到位，這才是影響生產力的最大因素。堅信「我的產品未來絕不會這麼龐大「，效率自然就上去了，至於你用不用大框架，效果都是一樣的。
PS： 真搞大了怎麼辦？這需要考慮嗎？看上什麼，就挖什麼人，想怎麼搞就怎麼搞唄。
==============================
下面也來說說我對開源的想法。
為什麼那麼多公司都搞開源？
個中緣由值得思考。個人認為，所有開源的東西對於其公司來說都是無關緊要的。如果這個技術是你的核心競爭力，請問作為老闆你會告訴全世界嗎？按照目前的趨勢，所有互聯網公司之間都是直接競爭關係，這沒有任何的行業區分。甚至，可以去掉「互聯網」幾個字。沒有任何公司會幫助競爭對手提升生產力，有的只是幫助競爭對手的對手而已。
所以，我認為開源的目的從來都不是響應什麼開源精神，對於個人來說可能是情懷驅動，但對於公司來說只有利益。或是營造生態圈、或是借開源力量完善技術、或是打擊對手、甚至可能是純粹為了KPI。好吧，微博上轉發時候是覺得好玩，畢竟大半夜的，加上前面看了幾個笑話，勁還沒緩過來。我剛看覺得作者可能是在開玩笑，而且我自己有有點這種感覺。
我剛昨天晚上整理了關於 respo 的文章，算下來最近公司里不碰 react，稍微碰點 vue，其他的代碼都是 respo 寫的，也有三個多月了。respo 是我用 clojurescript 模仿 react 寫的庫，過於簡單，但也算能用。
對於 react 的態度我大概也是這樣，react 作為一個項目，本身的想法其實可以走得更遠，比如說 clojurescript 那種整個語言的不可變數據，基於 lisp 語法的強大抽象能力，在保證了整個底層的嚴謹的基礎上，上層可以探索更有意思的編程手段。
然而 react 作為一個流行項目，同時有大量的項目正在使用，就像 JavaScript 面對的問題差不多，不可能把 jsx 就廢掉，很難脫離 js 再使用新的語言，只能漸進優化, 否則已有項目怎麼辦，基於它開發的各種 react native 怎麼辦，社區里大量 js 開發者怎麼辦。
我的立場大概和文章作者不同，我早先寫 coffeescript，現在寫 clojurescript，表達能力都很強，讓我對 js 從來就是排斥的狀態，更不用說 babel 那個棧。react 社區常常能聽到 jsx，webpack，hmr，immutable 整個棧太深的問題，即便 react 本來思路很簡單，但要整掌握下來全套的工具非常不容易，我也就因為接觸時間長還覺得能忍。
但是拿 clojurescript 對比的話，能把 clojurescript 掌握下來其實大部分概念都知道了，然後學學怎麼用就好了。而 js 的問題在於本身還是非常 low level 的語言，新手學會了 js，然後想掌握 react 精髓，中間仍然隔著大量的技術細節，而且是仍然在完善當中不斷被改進的細節。剛學的東西很快要更新挺累的。
我最初開始用 react 的時候，原因是 backbone 的 view 很多細節處理起來非常累，react 能大大簡化 dom 更新，至於其他地方怎樣，其實都沒仔細考慮，直接用 backbone 的舊代碼，然後慢慢改。但隨著 react 影響到數據層代碼，問題漸漸呈現出來，事情沒那麼簡單。你有個 redux 要設計，還要去為非同步抽象專門學語法，redux 同時再不斷改進，你要不停跟進才行，再說理解不一致也會導致額外的成本。
所以 react。的發展相當大程度是跟 Facebook 公司和生態綁定在一起的。小公司來說也許要遇到好多場景，比如說不想要複雜的 store 抽象，比如說用了冷門語言 coffeescript，比如說為了後端渲染要編譯 virtual dom 到靜態模板，而這些並非 Facebook 優先考慮的事情，也沒這麼多精力在如此多戰線同時打。
所以當普通人去學 react，去看教程，官方的其實就是 Facebook 所需要的，babel 啦，class 語法啦，要說是負擔也不為過，要說是陰謀讓很多人會心一笑。react 那麼簡單結果那麼多人流向 vue，怎麼可能簡簡單單就能解釋的。
其實我個人覺得 react 能挖到這麼多函數式編程的概念是真的觸及編程當中理論套路很深的部分了，mvc 的模式和 FRP 的模式怎樣思考怎樣演進，virtual dom 怎樣做高階變換怎樣完成性能優化，還有 immutable 究竟如何整體地對 react 生態形成影響。我覺得 Facebook 的人還是實用主義，有什麼用什麼，不會像我們 clojure 社區的人仔細去思考 js 語言層面的問題對 react 的傷害以及 clojure 到底多優秀。那麼大家其實都沒法阻止 react 生態變得越來越複雜，就像 js 變得那麼複雜一樣。
當然像我這樣直接喜新厭舊換一門語言好像有點不負責任，還好我從來沒喜歡過 js。不管怎樣 react 不再是它曾經宣傳的那麼簡單了，這一點大概對很多人會是一種傷害。這些是站在我的立場的一些想法，和原文有偏差。但換個角度看 Facebook 作為上市公司不可能花錢做公益，肯定是為了切身利益。不是常說嗎，為什麼辛辛苦苦寫軟體還免費開源出去，某個現實的利益不就是讓人幫忙試驗 bug 嗎。外部的開發者想要達成自己的訴求，恐怕還得自己努力。反正看到有同學發 react-lite 我也不避諱搞出個 respo 想反過來黑 react 了。
Respo https://github.com/respo-mvc/respo原文被刪了？已經看不了了，但是reddit上有個人說的很對
&>better title imo:
ReactJS is a tax Facebook levies on startup web developers who did not properly evaluate React before adopting it.
因為每個前端框架都有各自的優缺點，所以在技術選型時就必須根據自己的業務場景來進行篩選，除了業務場景，再有就是要考慮水平問題，React這麼一個框架擺在那裡，對有的人來說很簡單，合口味，對有的人來說就是難，所以說這肯定也是技術選型的一個重要考慮因素，學不會還強用，那就是交智商稅了。
框架的選擇權在開發者手上，React不適合就應該果斷放棄，不然就像鞋子一樣，質量再好，size不合腳也不行，但你也不能說鞋不好，買時候想啥了。。。
現在連做技術都不純粹了，好悲劇啊
這的確非常有趣。使用react過程中，發現開發時間明顯長於ng1的開發時間。使用redux做數據更新過程也很長。很多時候遇到的問題需要大量google，甄別出已經過時的內容。此外由於是虛擬dom，有些行為用起來就會比較麻煩。
但是圍繞其生態圈做開發，好處就是有社區做支持。另外，代碼維護起來也方便一些。如果是小項目，我建議不要使用react，會增加複雜度。如果是大項目，在人手有盈餘的情況下可以嘗試嘗試。React初始開發效率差，就像Java一樣，我寫個HelloWord還要專門寫個類，還要去搭建個環境。React性能也不行，比Vue差了不少。但如果真的是初創公司，我個人經驗來說還是會用React。用React並不意味著用React本身，還會捎帶上Webpack、ES6等等很多東西，這些東西學習曲線很陡峭，但是從另一方面來說還是會嚴格規範的，對於不懂的人，你可以直接以類規範封裝，總好比原本直接操作DOM，喵的壓根不知道他在哪修改了頁面屬性。二個是作為初創公司，你壓根不知道你的產品會是啥樣子的，需求一天三遍的也是正常，那麼這種情況下你就必須保證你代碼之間的職責分割與可復用性，我覺得React的Dummy、Smart、Container等等分割就挺好的。老實說用Vue的時候，還是會不可避免地以頁面為單元來寫，一旦發生了需求改變，呵呵噠。不過，如果像要寫微信內單頁面這樣又需要考慮性能的，還不如裸寫呢。總而言之，React以較為嚴格的規範保證了稍微點的代碼通用規範，好歹你組件內的代碼不會再污染全局。另一方面，JSX本身雖然醜陋，但是也能增大開發效率。不知道 GitHub - acdlite/react-fiber-architecture: A description of React"s new core algorithm, React Fiber 會不會較大地增加性能。
創業公司，最近嘗試把部分需求改成React來實現，說下觀點。
我們是一家集裝箱物流公司，對於集裝箱有著大量的欄位要處理，例如箱子屬於什麼型號，什麼類型，名稱等等。基本上一個單子有上百個欄位，每一個欄位都具有各種關聯，所以交互並不可少。開發前我們並沒有考慮到數據有如此之大，第二也是為了讓用戶能在老版本的瀏覽器上使用。我們的解決方案是fis+smaty+less+jquery，雖然都是模塊化開發，但還是操作DOM元素來響應數據的變化。現在，我們面臨的這麼一個問題，欄位上來後，操作越來越複雜。所以在開發新功能甚至在維護之前的代碼的時候特別痛苦。在訂單操作部分也重構了不少次，但並沒有有效解決目前面臨的問題。
我們前端共3人，是一個很小的初創公司。我打算把react融入到目前的系統中。一周時間，在原來的fis這套架構中，我在一個大的模塊中加入react+redux+es6，並且把基本組件用react重寫了。我覺得這個開發效率在我們團隊來說是可以接受的。所以我覺得在創業公司，起一個react的項目是完完全全提高開發效率的。對於說人員配置問題，其實看看文檔，多寫就可以完成簡單的業務。而對於剛入職的新員工，未接觸react的人來說，思想是關鍵。因為react不僅僅是虛擬dom，其主要的思想就是數據催化view。
但有時候，我們還是只需要jq。為什麼？因為你在一些項目是不需要react的，因為那些項目沒有數據，比如公司官網，比如博客。
存在必合理。沒必要去糾結，也沒必要去黑。作者是工程師還是畫頁面的啊？有點工程思維好伐？
第一條，憑什麼說fb「剝奪了」你的敏捷性？你們自己選擇的tech stack啊。笑死我了。
就敏捷性來說，我真不知道作者指的是什麼。包括所謂「開發效率」：你們考慮過項目的整個生命周期嗎？拜託了，你們不是兵啊，是工程師，動點腦子，Getting *shit* done fast 這種想法很沒有意義：一個軟體項目是活的，沒有done這回事，不是本地功能跑通了就行了，還要維護啊，而且會出bug啊，還要加功能啊、還要優化性能啊、對吧，應該考慮的是如何正確地、低成本、可靠地解決一個工程問題。
怎麼說我們在做的也是軟體工程啊：對於大工程來說，可復用的組件、可控制的state總是好的，
其實就算你不用現代框架光用jQuery也可以實現，只是要寫一大堆binding而已，還要手動碰一大堆的DOM。從數據流動的層面上看，這樣的代碼並不清晰，甚至很危險。退一步說，你可以應用一些稍微比較優秀的實踐，比如邏輯與樣式的選擇器分離（data-hook）、比如說前端模板引擎，但是也很浪費時間而且不可靠啊，為什麼不讓框架handle？很多邏輯包括CSS你都想要做成scoped，這個也要花費大量的時間和精力，然而如果你的技術棧先進，也就是配個loader的事兒；綜合來說，要做到可維護、高性能高可靠性，同時管理好所有的listener和state，不用現代框架比用現代框架（比如react）用的時間更多。而且用jQuery瞎雞巴搞出來的東西，我都不知道你怎麼測試，之後出了bug還有可能是組件間互相影響的，非常恐怖。話說這文章連個署名都沒有，好垃圾啊，這種東西也看？說react曲線陡峭..我才不信了..說什麼用字元串嵌套dsl的東西好上手..我才不信了..
對這種言論不意外，沒了解之前我也是個react黑，react一整套工具鏈復不複雜？相比mvvm和傳統w3c那套，肯定複雜很多，因為react要解決的問題遠比他們複雜，維護邏輯控制表現的一致性，讓所有組件的數據流看起來一樣，這問題太難了，它不是一種簡單的擴展，而是在w3c上hack出一個全新的應用開發層次，在沒有完全推廣成熟之前，基本上就是一個學習曲線非常陡的大坑，沒有爬坑的覺悟，別跳。
PS. 一致性的問題，或許沒幾個人能聽懂，這麼說吧，用現在用得最多的mvvm來說，很簡單，我要開發一個指令，因為現有的指令太不貼合業務，用現有指令構造這個邏輯非常繞非常冗餘，那麼現在告訴我，這指令我要怎麼實現？我是否能獲得一個指令開發層次？能令我快速開發這個指令？然後你就會發現，如果你要創造一個可以快速開發指令的層次，其實大家面對的問題是一樣的，你希望有層次性的作用域，有程序式的條件控制和循環控制，另外由於你要控制的是一個系統外的表現資源，你還應該獲得一套與渲染過程同步的生命周期方法，最後，你得到了一個react。看看目前那些mvvm的指令列表吧，if else foreach再加一堆數據綁定和作用域的指令，老實說，太核突了，控制結構和作用域，那些語言天然就有的概念為什麼要強行實現成指令呢？為什麼不能反過來？只要能在js更好地表現出html，其實我們能更好理解的，因為構造一套布局映射和比對方法，遠比構造一堆沒有內里邏輯一致性的指令要直觀得多。對於jquery前端是這樣。。。
不過react開發效率確實不怎麼樣。
用ng1的時候，我大罵數據混亂，日子過不下去了。
用react+redux之後，我大罵開發效率低下，玩的時間都沒了。有個故事：有座山兩個農夫分別造個2個橋，A逢人抱怨B的橋不好，就跑進去參合，甚至一起抱怨B的橋，那些喜歡B的橋說你A橋也有問題啊。A橋說沒有提過自己的橋，不是為了宣傳自己的橋好，只是評價B橋不好而已一篇無署名、無代碼佐證、頁面風格奇陋無比的個人主觀意識的辱文，不知道為什麼會被這麼多人關注。甚至還有陰謀論，就和扎克把身家99%捐出去是為了避稅，以及他娶了個貌陋的中國妻子，卻無視其妻的哈佛學歷。以及我就是扎克我應該怎樣，facebook 開源只是為了競爭、招人等等野心。卻沒人說Google開源，Vue開源作者收到月入4w+的捐贈呢？知乎技術圈什麼時候把開源變成一種陰謀論了，真可怕。以下是僅代表我自己的React開發的技術體驗，不代表任何人，僅供參考：大多數人遇到的問題，主要還是在於前端工程化和組件化思維的障礙。但是這是前端開發的一種趨勢。不論你現在使用的是Vue，抑或是Angular1.x / 2.0。
所以使用Webpack + ES6 + BABEL 基本上是在目前主流框架上都會遇到的問題，可以通過現成的腳手架，完成構建。例如
1、使用官方提供的腳手架（create-react-app）npm i create-react-app -gcreate-react-app init hello-worldnpm start2、使用github的boilerplate提供給基礎較好，專註於性能和最佳實踐GitHub - mxstbr/react-boilerplate: A highly scalable, offline-first foundation with the best developer experience and a focus on performance and best practices.提供基本的React/Redux/React-RouterGitHub - davezuko/react-redux-starter-kit: Get started with React, Redux, and React-Router!
提供目前最新的前後端同構的，可以當做項目使用，直接把代碼寫到Router/ComponentGitHub - ctrlplusb/react-universally: An ultra low dependency node v6 universal react boilerplate with an amazing dev experience.React最敏捷的開箱姿勢一、先把頁面所有HTML代碼寫入JSX里。代價是1、class 需要替代成 className2、inline style屬性需要更換成Object（我 相信很多人會把 inline Style 寫成 className ）這一步其實不需要做例如class home extends PureComponent { render() { return ( ... ) }}再來個漂亮的格式化，我想vue template語法估計不太好格式化吧。推薦VSCODE二、先做功能，再拆組件1、以下簡單實現了雙綁、filter、IF、Map等const Why = { ifShow } =&> { return ifShow ? && : &- } & ) }}class List extends PureComponent { render() { const { ... } = this.props; return (&
GET(url,parameter).dispatch( state, playload =&> playload)
串列：
GET(url,parameter).mergeMap( data =&> GET(url2))
並行：
GET(url,parameter).merge(GET(Url2)).reduce(..).dispatch(...)
再比如：
fromEvt(e).mergeMap( data =&> GET).dispatch()
或者
fromEvt(e).mergeMap( data =&> GET).setState( data =&> { ... } )
只要你會Javascript，寫React真的很輕鬆。架構沒有銀彈，黑魔法也不是萬金油，合理利用架構優點去實現項目。但是了解它帶來的優點和缺點，不是更有利於項目，不是嗎？
React全家桶的基本思路是維護代碼、調試問題比純粹的特性與版本開發困難，所以把成本轉接到框架學習與開發時期的一些約束上。
如果不認同這個思路，尤其是希望達到最快的初始速度，就真的別用了，會很不開心的。react 不過是個包
沒有眼光和能力, 但是又有奇奇怪怪的信仰, 自然會發生買包的事情
信仰不夠堅定, 就會後悔買包
為什麼國外那麼多公司用 react 以至成為風潮？
因為金字塔底部的磚塊永遠是最多的。那麼為什麼國內也有這樣的趨勢呢？
因為自卑, 盲目崇拜國外, 覺得國外的包肯定好那麼為什麼被洋包致盲呢？
因為自己本身水平有嚴重的問題嘛