詹彥橋、朱超強、趙鵬等人表示贊同。
如果是技術選型的研究，除了好處，還要了解壹些需要註意的問題。以下隨便列舉，僅供參考。
1.不要陷入糾結工具的怪圈。
當我們團隊開始使用React時，工具棧應該是grunt+grunt-React；；寫了壹段時間覺得有限，然後老板帶頭把工具換成了Gulp+browser ify+watch ify+react ify，然後我開心地寫了大概半年，發現熱門庫都在webpack上；所以我們的工具棧就變成了gulp+webpack+babel-loader。最後大家壹致認為gulp是多余的，所以我們的工具棧是圍繞webpack重建的。我最近在負責壹個內部項目，比如hot-module-replacement，extract-text-plugin(讓妳要求用js ('style。scss’)；這樣寫的東西)都是瞎編的。當然後來因為業務需要，我們基於webpack搭建了自己的搭建工具，這是後話了...
這段近壹年半的歷史告訴我們，1)前端是個大坑，1個月不學習新知識，就會被社區遺忘。2)現在妳真的很開心能上React，工具棧也基本穩定了(怎麽看妳還不知道怎麽用webpack！)，不要花太多時間糾結。
PS。HMR就是這樣。雖然dan玩的很精彩，但是我其實發現項目裏大家還是習慣手動Cmd+R。
因為重建需要1和項目大後的2秒。
2.DOM操作不可避免。
但是對於任何壹個稍微有點規模的前端項目來說，沒有DOM操作基本是不可能的。更不用說最常見的後端“埋點”了，還得用DOM API取值；只說最簡單的壹個，比如右手邊的“返回頂部”按鈕。妳只要用React寫壹個。當然，妳會說什麽？requestAnimationFrame？反應訓練小組什麽的？當妳真正去項目的時候，妳會發現DOM API很簡單。
3.擁抱ES 6，擁抱React v0.14。
為什麽把這兩個放在壹起？看，因為React v0.14中提出了壹個全新的組件概念叫做無狀態功能組件。看起來是這樣的:
var Aquarium =({ species })= & gt；（
{getFish(物種)}
);
有沒有發現被傳統的createClass方法簡化了？當然，像這樣寫組件有很多限制，比如不能聲明各種生命周期方法等等。，但在常見的前端業務場景中，純渲染組件不在少數。引入這種語法後，我們可以更方便地提取這些組件進行重用。
此外，擁抱ES 6還有很多好處，比如加載依賴項不需要var XXX = require(' XXX ')；那麽var y = xxx.y可以直接從“xxx”導入{ y }；簡單明了。
生態環境還在成長，坑很多。
其中，首先要批判的就是react-router。我們從v0.10開始用，現在是v1.0。妳知道我們為了升級這個東西改了多少次業務代碼嗎？妳看，我們每次升級API，都要改，不能抱怨。終於明白了v0.11，寫了壹篇技術文章分享在博客裏。結果後來幾天各種催單...壹個月前，我花時間重寫了0.13版本的教程，這個版本又發布了，API基本不壹樣！！不壹樣！！壹樣的！！樣本！
當然除了坑還有很多優質的生態環保產品，比如螞蟻的螞蟻設計。
5.服務器端的渲染非常漂亮，到目前為止我們還沒有看到任何使用的scale產品。
可能是我無知吧。請在評論中跟進。我摸索著寫了壹個最簡單的服務器端渲染，但是如果把這個邏輯放到我們現在的業務邏輯中，幾乎可以直接出手了。要實現服務器端渲染，需要付出太多代價。
6.反應既簡單又困難。
很簡單因為React的API真的很少見，官網各種文檔壹個下午就能看完(現在看Angular……...).但是當妳覺得自己真的懂React的時候，看看React源代碼分析系列文章開頭提出的問題setState的解密——pure render——zhi Hu專欄。有多少人能不假思索的正確回答？(對了，安利我們團隊的知乎專欄目前處於死黑React狀態)。
當妳真正在商業項目中使用React的時候，妳會發現它的生命周期比妳想象的要復雜。它的API背後的邏輯比妳想象的要麻煩。當然，首先妳得踏入這個坑。
7.作為翻譯之壹，我為樓上的壹個家夥感到抱歉，他說《反應:未來用戶界面開發框架》這本書太難回答了。作為補償，所有買這本書的同學都可以通過拍照來問我React相關的問題。
最後，安利壹下我們團隊的專欄:純渲染-知乎專欄。
8.在夢中醒來。補充壹下，巴別塔6到目前為止是個大坑。在商業上使用的時候，壹定要註意它和巴別塔5的巨大區別。(關於這個補充點，要明白的是，巴別5為了讓大家愉快地使用ES 6，做了壹些不規範的改造，這些改造在巴別6中已經去掉了。所以如果在Babel 5下編譯正常代碼，在編譯Babel 6時可能會出現錯誤。這個問題不能完全算作巴別塔的坑，但是會影響妳的開發進度)