React Native是否會是下一個技術浪潮？

01-11

1.React Native（RN）已經開源一年，是否可以看出RN是下一個技術浪潮？
2.微軟開始支持RN，是否說明RN是未來的趨勢
3.作為前端新人，努力提升JS能力的同時，是否需要開始入手RN

4.入手RN，在 RN for iOS 和 RN for Android 中該選擇哪一個

react實際是思想上的一次勝出。現在編譯器製作越來越簡單，從語言到語言的翻譯器成本下降，將來javascript（es5）可能會成為一門中間語言，在這之上比如說reason，typescript，es6，java，oc都可以寫。雖然js未必會一統天下，但翻譯器節省了跨語言的成本。

另外用函數式組織數據流，oop寫組件的架構，慢慢會成為主流。比如rxjava，其實思想是一致的。react火是因為提供了更新的思想，解放了生產力。

rn會不會成為主流？我認為rn無論成敗，這種思想一定會慢慢成為主流。在傳統的oop思想上，程序員需要掌握大量的設計模式，需要理解耦合，而耦合是oop複雜度的核心。耦合很容易產生，卻不好解決。那麼redux這類工具其實大大降低了程序員實際需要的經驗。當然我認為redux再前進一步就是建立在rx基礎上的cycle了。

思考一下，看看很多android和ios組件庫，裡面大量程序使用了狀態機。而現在程序員，有幾個能從一開始就把程序建立在狀態機上？所以說rn是思想上的進步。使用新思想，總不會吃虧。

順便吐槽下weex，weex當然可以做app開發，他模仿了react native的技術理念，比如virtual dom，js bridge。但它忽略了非常重要的一點，前端工程化的思想落後了。它沒有很好的數據流組織。這才是致命的，思想的落後。就好像v8不是真的代碼質量多高，而是v8第一次意識到機器變快了，內存變多了，咋們不要再給用戶省內存了，我們拿空間換時間吧……

補充下，居然忘了回答樓主的問題，前端新人要不要學rn。我現在帶前端團隊裡面有native工程師和js工程師，我覺得rn還是學吧。但既然是新人，又是前端，就要問下自己css，js，es6、7，webpack，gulp、node，react，redux這些應該掌握的知識是不是已經深入學習了。再比如說函數式編程，諸如柯里化、純函數、reactive programming等概念是不是掌握了。

既然是新人，新人在這幾年有幸做前端，在舊知識迅速過時的今天，還是挺容易把握技巧超過前輩們的。既然是新人，新人通常比較辛苦，也容易delay。那如果本來團隊要用到的知識，沒有學好，貿然學rn，還是挺痛苦的。就會陷入兩難，別人用的你不如別人，不用的沒人欣賞你

最後一個問題react ios和react android學哪個？我覺得都學吧。畢竟一門技術不學紮實，你怎麼證明你在某方面比別人更具備專業性？而且深入學習也更容易有所得。

以上

瀉藥。

最近在做React Native，特別想說下JavaScript實現的CSS子集比想像的好用，加上JS本來有的變數和Object spread(基本等同於mixin)，函數，模塊等等，效果並不亞於Sass / Stylus，而且可以痛快地寫flex，樣式代碼也不會過與亂七八糟。當然因為沒繼承的原因，JS內聯樣式管理還是個很大的課題，需要多做研究，但是JS控制樣式，潛力還是很大的(可以回想下現在前端有多少狀態都是JS判斷切換樣式的，CSS早就不夠用了，在語言內的表述要比無類型亂對名字好)。

界面比原生好調，邏輯和介面也好寫，性能不錯。

很多場景已經可以用了，效率非常高。

問題就是現在用的人不多的時候，大家都在探索，對工程師要求比較高，OC，java，js需要互相學，並且熟悉其他平台的生態。現在社區組件雖然很多，但是良莠不齊，也很少有成型的組件庫，相信隨著時間的推移這些最終都不是事。

既然安卓已經在去年年底發出來，沒有嚴重問題。借著React.js本身氣吞山河的其實，估計今年會迎來一個小爆發。

總結：運行 / 開發速度雙感人。熱更是絕對亮點。

結論：對於不喜歡嘗試新技術的朋友建議觀望，比如接SDK之類的需要坐等社區封裝。喜歡折騰的朋友一起來玩吧，非常有前景的技術，因為大部分APP的場景根本就類似前端，沒必要用OC，Java這種重型平台，再算上沒熱更跟孫子似的等審核，有心氣強烈建議React Native。

展望：React Native由於可以封裝雙平台，還有React本身的組件化，雖然現在免不了還要經常碰OC / Java，可以想像未來許多多平台UI和各種SDK都會被統一用JS組件封裝，開發會趨於簡單快速地用JS搭積木，這對國內吸引力是非常大的（看看所謂"H5"在國內的火爆程度吧）。當然按React興起的速度來看，React Native迎來黃金時期還要明後年，但是要走在潮流前面堵著才比較好不是:P

補充下對比原生和"H5"的優劣勢：

對原生：開發快，原生開發要寫兩個平台。運行慢一丟丟，但大部分場景無壓力。決定因素是代碼85%可以雙平台復用，如果有Web站也可以復用幾乎所有邏輯代碼（現在Router復用還不是很好，但是可以用類似Server render的架構封裝下統一起來），然後只是簡單修改不同平台的視圖就可以了。

對"H5"：運行快很多，開發速度差不多（也許有人不同意，這個要看實際情況，由於沒有平台的API H5後期會被各種細節優化如滑動，滾動和各種奇怪安卓兼容搞死，只能反覆hack，最終被拖掉很多時間，也非常上火）。可以調用各種原生API，PM要以這種那種方式調用攝像頭，電量，獲取定位信息等等的奇思妙想……就不用讓Native開發者非常麻煩地寫很受限的SDK來供你使用了。

來非常認真嚴謹的針對題主的問題回答一下。。

http://1.XXX已經開源一年，是否可以看出XXX是下一個技術浪潮？

顯然不是，開源死掉的東西一坨一坨的，開源一年也沒人看的東西多了去了。。從「開源一年」這一點看不出任何結果，所以當然為否。。

2.微軟開始支持XXX，是否說明XXX是未來的趨勢

這應該是聖地亞哥的威廉伯爵做的事情，反而微軟來做容易被黑。。從統計學的角度來說，被微軟支持和是未來的趨勢並沒有正相關性（1%哭暈在廁所），當然也不存在因果性，所以也為否。。

3.作為前端新人，努力提升JS能力的同時，是否需要開始入手XXX

既然問的是「是否需要」，那當然是否，沒有那個庫或框架是非學不可的。。

4.入手RN，在 RN for iOS 和 RN for Android 中該選擇哪一個

用 RN 難道不是為了多端么，你就開發一個平台還刻意用 RN 幹嘛。。

觀望。目測會有一大批人嘗試，踩坑，填坑。

最近利用業餘時間接觸了一下react native，利用one 的api寫了一個demo：https://github.com/wutongke/react-native-one，說說開發體驗吧，開發工具用是webStorm，debug使用chrome+react插件，開發體驗不錯。

先說下react native的優勢：

開發效率高，確實很高，react native封裝的控制項、布局都是傻瓜式使用，幾行代碼就可以開發出一個還不錯的界面。
不得不提的跨平台……

說下開發中遇到的坑：

iso和android兩端同樣的代碼有挺多顯示不一致的地方。
卡頓問題，ios上還算流暢，android上不想吐槽，使用體驗較差，彷彿回到了android2.0時代。
android端適配問題，想想android原生都有很多兼容問題，何況使用非原生代碼。

感覺跨平台一直都是一個趨勢，但是一直還沒有掀起所謂的浪潮，react native應該也做不到……

說不定weex先火

reactnative當初是facebook的要下崗的phper們瞎搞的

virtualdom本來是mithril這些原創的不過沒人注意

fb的phper讓你覺得vd是他們原創的其實不是

htmlinjs這是坨標準的屎客戶端從來沒人這麼寫xmlincode 除非哪個發神經

reactnative當初過不了ios的uitableview關（現在也不行）基本無解

這關 javascriptcore性能大約是oc native的1/4~1/3的樣子 v8的一半

即時運算完全不行數據量一大沒法看 phper發明了非recycle的listview 不過數據量一大一樣性能爛的一b

但是總得給自己找點事讓自己看起來更專業啊

scrollview和tableview是apple的ios倆大發明之一 ios屬於超級重度使用這你性能搞不定（也根本搞不定蘋果的javascriptcore比v8的性能都弱了一半 v8性能幾乎到極限了速度還是c++native的一半 oc native的7成）電商社交新聞論壇app都沒法實用跨個球平台啊

uitableview在ios上可是重度使用控制項使用度幾乎排到第一位

reactnative的listview性能差

這些小札知道不過他知道一說跨平台 js操縱ui native 加上facebook的名頭估計不少人跪舔另外拉更多人入坑對facebook倆好處

1.讓react的屎seo搞得google頭大要不添加上百萬台伺服器解析jscode 增加google搜索成本對fb不是嘛壞事

2.別人都reactnative，fb whatsapp用native facebook不是甩跪舔者百條街不是

於是推

於是許多人上鉤了

遇見uitableview即時運算js不給力這事 facebook的rreact native團隊就是裝傻反正這世界的跪舔者眾多還無腦裝傻足夠應付他們了

---------------關於c objective-c v8 javascript的性能參考如下（facebook都知道裝傻）--------------------

Operation Performance Evaluation

Tech Tuesday: iOS Programming

ARE WE FAST YET?

https://software.intel.com/en-us/articles/graphics-acceleration-for-html5-and-java-script-engine-jit-optimization-for-mobile-devices

Writing Fast, Memory-Efficient JavaScript

http://www.slideshare.net/paullfc/js-engine-performance-10916857

virtualdom的早期庫至少先於react 性能也超過react（virtualdom庫有時我也用至少比控制你的js框架好）

Mithril

另外關於native跨平台qt/qml delphifmx很牛

但是lazarus（opensource delphi）也足夠闡明跨平台是嘛樣的了

這三個基本是native跨平台（c# java可不是native）的世界範圍的top3了

Lazarus Homepage

這幾個偶都用 rn不用嘿嘿

謝邀...

沒做過這方面的

但是就發展前景來說還是不錯的，畢竟純web的app體驗還不是很好，純native的多餘內容的變化不太靈活，兩者有效的結合還是不錯的

當然具體應用具體分析，並不適用所有情況

我用過RN寫過一個瀏覽圖片的小應用

說實話吧，RN那個樣子，跟大多數人心中的前端離得有點遠了

我在寫RN的時候感覺都不是在寫javascript了

然後並沒有。商用app還是首選2套開發工具。乃們只看到佈道師們說這個開發起來多麼便捷，但是前提是這些大公司的團隊裡面已經有不少水平不錯的android和ios背景的工程師，能在沒有現有的庫的情況下自己實現一套js以外的平台相關的api。而創業公司依賴的各種第三方服務，如推送、IM、以及其他。。。一般第三方只會提供2套平台api，有的撐死會有cordova的api。可是react native的api，真心是沒有。。。

react native 註定不會是一個技術浪潮。哪怕做到了原生的 80%。實際上，使用 RN 開發一個完整正式的應用絕對不是網路上那些所謂「高仿」某App一樣的簡單。RN 開發其中的很多坑是需要自己去踩去填的。

我司也使用 RN 開發。但是使用 RN 的前提是我們有 Android 和 iOS 方面的 native 開發人員，可以在 RN 不滿足情況下自己實現 RN 插件。

但是即使如此，使用 RN 開發的產品也只用於交互體驗要求不很高，尤其是布局上很少有要求主動 measure 、animation 方面又沒啥要求的產品。

如果本身就是做前端的可以去學一學 RN 。

但作為一個本身就是寫native的程序猿來說我swift都可以跨平台還弄RN搞毛我整配置的時間是我寫代碼的兩倍。

實際上RN也是Hybrid App的一種，跟PhoneGap這類的區別就是界面渲染性能有所提高，優點和缺點都被繼承了。優點多了個性能更強，缺點還是一如既往，複雜的功能還是需要寫原生代碼。所以我認為並沒有做到本質上革新，作為老的Hybrid的升級方案當然是好的，但是替代Native App還有路要走。

RN能滿足80%的需求，在這種情況下能大大提升開發效率，前提就是你的應用不會涉及到另外那20%，所以目前並不是一個純前端方案，還要熟悉客戶端開發才能用好。

至於是不是下一個，我覺得應該算在Hybrid App這個浪潮里吧，這一波一直在持續。

有哪些應用場景是一定不能用RN或者weex這種方案的？建議比較了解的告知一下新手們，以免進入雷區，無法抽身。。。。

對於運營來說熱更新簡直不能再棒

對於程序來說巨坑千萬別上

不會，強行跨平台真是太愚蠢了。

當然我是渣渣，沒資格說這話，我面壁去了，不要罵我。

目前來看，不會取代原生開發

有那個大廠出了相應的APP？

會火，但不會取代原生。