React native充分利用了Facebook的現有輪子，是一個很優秀的整合作品，並且我相信這個團隊對前端的瞭解很深刻，否則不可能讓Native code「退居二線」。

對應到前端開發，整個系統結構是這樣：
JSX vs HTML
CSS-layout vs css
ECMAScript 6 vs ECMAScript 5
React native View vs DOM
無需編譯，我在第一次編譯了ipa裝好以後，就再也沒更新過app，只要更新雲端的js程式碼，reload一下，整個介面就全變了。
多數佈局程式碼都是JSX，所有Native元件都是標籤化的，這對於前端程式設計師來說，降低了不少學習成本，也大大減少了程式碼量。不信你可以看看JSX編譯後的程式碼。
複用React系統，也減少了一定學習和開發成本，更重要的是利用了React裡面的分層和diff機制。js層傳給Native層的是一個diff後的json，然後由Native將這個資料對映成真正的佈局檢視。
css-layout也是點睛之筆，前端可以繼續用熟悉的類css方式來編寫佈局，通過這個工具轉換成constrain佈局。
系統只有js-objc的單向呼叫，就是把原生UI元件的方法通過javascritcore或者webview（低版本iOS）對映到js中來，整個呼叫過程是非同步的，這樣的設計令React native可以讓js執行在桌面chrome中，通過websocket連線Native code和桌面chrome，極大地方便了除錯。對其中的機制Bang的一篇文章寫得很詳細，我就不拾人牙慧了：React Native通訊機制詳解 « bang’s blog 。但這樣設計也會帶來一些問題，後面說。
點按操作也被抽象成了一組元件（TouchableXXX），這種抽象方式是我在之前做類似工作中沒有想到的。facebook還列出Native為什麼和web「手感」不同的原因：實時的點按反饋和取消能力。React Native 這套相應機制設計得很完善，能像Native code那樣控制整個點按操作的所有過程。
Debug相當方便！修改了js以後，通過內建的nodejs watcher編譯成bundle，在模擬器裡面按cmd+r就可以看到效果。而且按cmd+d，可以開啟一個chrome視窗，所有的js都移到了chrome裡面執行，所以什麼斷點單步打呼叫棧，都不在話下。

上面的既是特點也是優點，下面說說缺點，或者應該說：「仍然遺留的問題」，在我看來，這個方案已經超越了Hybird方案。
系統仍然（不得不）依賴原生元件暴露出來的元件和方法。舉兩個例子，ScrollView這個元件，在Native層是有大量事件的，scrollViewWillBeginDragging， scrollViewWillEndDragging，scrollViewDidEndDragging等等，這些事件在現有的版本都沒有暴露，基本上做不了元件聯動效果。另外，這個版本中有大量元件是iOS only的：ActivityIndicatorIOS、DatePickerIOS、NavigatorIOS、PickerIOS、SliderIOS、SwitchIOS、TabBarIOS、AlertIOS、AppStateIOS、LinkingIOS、PushNotificationIOS、StatusBarIOS、VibrationIOS，反過來看，剩餘的都是一些抽象程度極強的基本元件。這樣，使用者必須在不同的平臺下寫兩套程式碼，而且所有能力仍然強烈依賴 React native 開發人員暴露的介面。
由於最外層是React，初次學習成本高，不像往常的Hybird方案，只要多學幾個JS API就可以開始幹活了。當然，React的確讓後續開發變得簡單了一些，這麼一套外來的（基於iOS）、殘缺不全的（css-layout）在React的包裝下，的確顯得不那麼面目可憎了。
另外，React Native仍然很不完善。文件還不全，我基本上是看著他的示例程式碼完成的demo，整合到已有app的文件也是今天才出來。按照官方的說法，Android版本要到半年後才釋出：Blog | React ，屆時整個系統設計可能還會有很大的變化。

PS，在使用Tabbar的時候，我驚喜的發現他們居然用了iconfont方案，我現在手頭的專案中也有同樣的實現，不過API怎麼設計一直很頭疼。結果，我發現他是這麼寫的：

更新於2月3日：關於我們的最新動態，我們把React跑在了其他Native的實現，讓React在無線不僅是ReactNative，就像我之前說的React更是一種模式：

對React的理解，認為React是一種架構模式，無論是內建的DOM、Native還是React Canvas都是的一種基於React模式的具體實現，當我們評價React Native還是評價React Canvas，都是React生態想象空間的一種表現。

React提出重新思考UI開發過程，其實不是面向瀏覽器，而是所有的前端，因為對前端開發而言我們需要涉及的領域已經開始包括了Web與Native。

這裡也分享淘寶基於React正在進行中的一些實踐，是我認為能戳中極客們的G點讓大家為了亢奮的事情。

React Web端

團隊裡最早使用React的線上產品: 知了，前端是React+KISSY, 後端是淘寶基於Node.js解決方案Midway，這是完全由前端主導的專案，在前端，通過React極大的方便了富互動頁面的構建，同時也輕鬆的解決了頁面內業務元件狀態同步等問題。

淘寶懂我，我們在面向使用者的創新業務裡毫無懸念的引入了React，不是為了技術而技術，而是基於React的開發過程，促使大家一切都是以元件的思考模式，這的確讓業務也變的更加清晰，開發效率提升，維護成本降低，發現React的確改變之前曾經非常困擾我們的事情。淘寶懂我的入口在“我的淘寶”裡，大家可以去圍觀: 淘寶網 - 淘！我喜歡。

React Native端

F8大會當天，React Native終於正式開源了，這著實讓人興奮了一把，因為我們知道React Native即將成為在手機端上必不可少的開發模式之一。因為已經有React的開發經驗，稍微過目下文件，很自然就能過渡到React Native的開發。筆者稍微努力了下，復刻了下手機淘寶的首頁，不到個把小時我這個菜鳥就差不多完成了大體的樣子，讓人驚訝於React Native這套技術方案的生產力。

而且React Native開發與Web幾乎一致的開發與除錯體驗，也更讓我驚豔，這效率上差距可見一斑。

但是，Android版本還未開源，React Native只支援iOS7+平臺，而在淘寶移動業務裡依舊需要支援iOS6平臺，所以在iOS6與Android平臺上只能暫時繼續跑H5頁面，在技術上我們很快就確定將React Native程式碼轉為H5版本，做到大家夢寐以求 Write once, run everywhere，就如大家在微博http://weibo.com/1797897057/CcFmN3nwp上看到的，我們就做了一個簡單的DEMO，基本確定這個方向的可行性。

興奮的同時，一個無法迴避的事實，對Web前端來說這是一個全新的領域，就是一個大坑，需要我們去填平，填平這些坑的就是我們配套的基礎設施。如圖這是淘寶基於React的已經完成或正在進行中相關領域，當這些基礎設施相對完善時，就是React Native爆發的時候，而我們現在做的事將是未來的肩膀。

結束語：Web是未來，Native是當下，而我們在未來與當下之間。
編輯於 2016-02-03 19 條評論 感謝 分享 收藏 • 沒有幫助 • 舉報 • 作者保留權利

69
贊同反對，不會顯示你的姓名
趙望野，《你不知道的 JavaScript》譯者
time david、ds dsdd、李飛 等人贊同
先說結論：必有作為，但絕不會是一家獨大，甚至很難成為主流。

用過 React 會知道，React 的核心概念是「DOM Representation」，在開發者和 DOM 中間構建一箇中間件，然後通過高效的演算法來 diff 兩次 Virtual DOM 渲染的差異，然後在最小範圍內更新 DOM，在大部分情況下——注意是大部分不是所有——這種做法都是足夠高效的，但是對於精細的需求、動畫控制等——比如在移動裝置上做一個跟隨 touchmove 的元素，還要各種 transition 等等——場景 React 會顯得力不從心，或者很笨拙。

但是拋開這些太過複雜的需求，React 是有能力滿足大部分的業務場景的。

再說 React Native，這幾天不停看見媒體用「Web 開發要 XXX」一類的題目來發稿，真是吐槽無力。React Native 根本都不算 Web 開發好不好——Webview 都沒了還 Web 個 bird 啊…

React Native 繼承了 React 在 JavaScript 的擴充套件語法 JSX 中直接以宣告式的方式來描述 UI 結構的機制，並實現了一個 CSS 的子集，這把「DOM Representation」的概念外擴成了「UI Representation」，由於不是操作真實 UI，就可以放到非 UI 執行緒來進行 render——所有做客戶端 UI 開發的都應該知道 UI 執行緒是永遠的痛，無論你怎麼 render，render 的多低效，這些 render 都不會直接影響 UI，而要藉由 React Native 來將改變更新回 UI 執行緒。

由於目前沒有任何示例程式碼，也看不到更細節的實現機制介紹，所以以下部分為猜測。如果 React Native 沿襲 React 的機制，就會同樣是把兩次 render 的 diff 結果算出來，然後把 diff 結果傳遞迴主執行緒，在最小範圍內更新 UI。

所以，核心是以下三點：
1. 在非 UI 執行緒渲染 UI Representation
2. 高效的 diff 演算法保證 UI update 的高效
3. 沒錯，由於中介軟體的機制，React 很有可能成為一個跨平臺的統一 UI 解決方案，可以理解為 UI 開發的虛擬機器？

宣告式 UI 開發，簡單快捷，必然大有作為。精細控制無力，複雜應用場景無法很好滿足，必然受限。

最後再說一句…不是能寫 JavaScript 就叫 Web 開發…

============================================
看了@Rix Tox 的答案後來補充。

這個答案作為補充或擴充套件來回答「React + Flux 模型」是非常好的，但問題是「React Native」。React Native 的亮點是解決了在 Native 中使用宣告式來開發 UI 的渲染效率問題，而不是軟體架構和工程模型的問題，無論是 iOS 還是 Android 固有的模型也是非常好的。為啥 FE 會在乎這個？因為 FE 最習慣用宣告式來開發 UI，而這麼多年想參與到 Native 開發中的目標都沒能達成，就是受制於最終的執行效率。

React 作為一個 View Component 封裝解決方案來講，同 Polymer 以及 AngularJS 中 Directive 並沒有本質區別，只是用不同的思路來封裝 View 而已，用 React 也不一定非得用 Flux 模型，React 替換 Backbone.View 元件，用純樸的 MVC 模型來描述也是 okay 的。但是當 component 很多且互相巢狀時，就需要有一個合理的模型來描述通訊機制，優雅且高效，那就是 Flux 模型了。前年 React 剛釋出，還沒有提出 Flux 時，我們在終端產品中開始小範圍嘗試 React 就遇到了 component 之間通訊麻煩或者不合理的問題，當時的解決方案是全域性例項化了一個繼承 Backbone Event 的物件作為 event hub，所有的 component 都在其上來 reg 和 trigger 事件。現在看來，就是簡化版的 Flux 模型。

不過我確實有一點遺漏的內容，React 的 DOM Representation 或者 React Native 的 UI Representation 的每個 component 都有一個 state 用來描述狀態，而 component 某種意義上來說就是一個狀態機，因此渲染結果是冪等的。

近些年 Web 前端的開發越來越多的受到工程複雜度上升導致整體效能下降的困擾，所以最近幾年的新型框架大多有一些獨特的機制來提升效能，而這些機制大多是從 Native UI 或者遊戲開發中借鑑來的，比如 AngularJS 中的資料 dirty check 機制，比如 React.js 中 Virtual DOM 的 diff 機制，這些特點同以前的前端框架或庫相比，真的是非常特殊且先進的改進，往往也會成為這個框架或庫的亮點之一，對 FE 來講當然就是新鮮玩意啦。

最後，Facebook 在 PHP 中直接寫 HTML Tag 那東西叫 XHP，對應是 JSX 擴充套件語法，和 React 關係也不大…
編輯於 2015-02-06 4 條評論 感謝 分享 收藏 • 沒有幫助 • 舉報 • 作者保留權利

6
贊同反對，不會顯示你的姓名
Vincent 4J
xiaogang、Jeremy Young、李喆 等人贊同
Facebook 在 React.js Conf 2015 大會上推出了基於 JavaScript 的開源框架 React Native，結合了 Web 應用和 Native 應用的優勢，可以使用 JavaScript 來開發 iOS 和 Android 原生應用。

下面是對 React Native 官方文件的完整中文翻譯教程：Facebook React Native 中文教程
釋出於 2015-04-25 新增評論 感謝 分享 收藏 • 沒有幫助 • 舉報 • 作者保留權利

5
贊同反對，不會顯示你的姓名
宋陽，各種心理扭曲的問題，烏煙瘴氣
yangxq、錢宇翔、xrush 等人贊同
其實最應該期待的是ui以及編譯環境的整合，這些已經有ionic做榜樣，js to native也有Ti趟了幾年雷。工程結構上比ionic的angular討巧。

看起來會牛的，但這些優勢目前我串不起來，沒法預期會是個什麼東西。

我多說一點，以我的觀察，沒ide火起來難。
編輯於 2015-01-29 新增評論 感謝 分享 收藏 • 沒有幫助 • 舉報 • 作者保留權利

WebView 裡無法獲得的能力雖然是「體驗增強」與「端基本能力」，但現都基本上有成熟解決方法。但後期的 UI 和 Layout 的效能反而是目前 Web 技術欠缺的。所以，無論是 Titanium 與 React Native 都是解決效能作為探索的出發點。

一、效能慢與快的分水領.

慢與快的標準，是按照每秒大於等於 60 FPS（60 幀每秒） 的理論，而為什麼是 60 FPS，這不多描述。

按此理論，那麼「每幀」裡所有的操作都必須在 16ms 完成。

二、WebView 裡 UI 效能慢的原因.

WebView 單執行緒模型；
DOM/CSS 排版複雜，在渲染上需要大量計算；
動畫是也很重要的考量因素。

多說兩句動畫。

最早做動畫都是用 setTimeout/setInterval。
而 setTimeout/setInterval 的處理回撥的時間 tick time 精度都在 16ms 左右。

所以，可以想象正常用這兩個函式就已經 16 ms了，再加 reflow/repaint/compositing 卡頓或跳幀就是家常便飯了。

還好的是 w3c 標準和各瀏覽器廠商較早就支援了動畫介面 RAF（RequestAnimationFrame 函式）來處理動畫幀回撥。解決了上述 setTimeout/setInterval Animation 不足的問題。

三、DOM 效能低下的原因.

瀏覽器執行的幾個步驟：

restyle/reflow/repaint 觸發條件：

瞭解完以上資訊，考慮以下條件：

把 JavaScript 邏輯、複雜的 DOM 與樣式合成，並完成渲染；
HTTP 請求下載多媒體；
在一個執行緒裡；
移動上的 ARM 架構；

以上操作能在每幀 16ms 裡完成，想想都覺得是一件 TMD「不可思議」的事情。
於是各種各樣的奇葩優化出現了。

四、WebView 裡高效能元件分類.

已知的高效能元件的幾類方法：

1）常規方法.

這類的原理主要是利用人為或規範的方式，減少 restyle/reflow/repaint 觸發次數：

通用元件優化 DOM 結構，甚至用 Virtual DOM（虛擬 DOM）減少 reflow 和 DOM 的複雜度；
優化 CSS，少用或跳過 repaint 階段。用編譯的手段識別部分 CSS，將 left/top 變換變成 transform；

跳過 layout 與 paint 階段，就是多使用 Layer composite 技術，即 css 的「opacity」和「transform」屬性作動畫。

只能在 css 和 DOM 結構上去摳出些效能優化的空間，缺陷優化空間有限；這種優化技巧通常是放在最後調優時衝剌使用，不能做為常規手段。

2）進階方法.

原理是儘可能利用 native 能力，甚至將 JavaScript 轉換成 native App 程式碼。

用 JavaScript 調起 native 元件，將增強與高效能元件交給 native 來處理，以前在 FEX 提的「輕元件」就是這麼做的。這個原理類似 PC 時代的 ActiveX；
將 WebView 裡無法實現的功能用 native 實現。
利用 native Activity 的渲染執行緒，分擔瀏覽器渲染壓力（WebViewCoreThread 是 WebView 執行緒）。
最 dirty 的事在於處理 native 上 UI 的層次管理。
需要後臺有執行緒一直在檢測 scroll/resize/ui change 時 UI 邊界是否有相互覆蓋與疊加的問題。
JavaScript 翻譯成 Java/OC 程式碼。類似 React Native/Titanium，將 JavaScript 翻譯成 native 程式碼，特別是 UI 元件上。（有興趣的同學可以反編譯 React Native 寫的 Facebook Group）
例：用 React，通過虛擬 Web UI 對映至 Native View，並且將程式碼邏輯翻譯成 native。

3）新方法 — Canvas UI.

這也是要說的重點，用「開發遊戲」的思路來做 UI 元件探索，我把它稱為 Canvas UI framework。

五、Canvas UI framework.

用遊戲的思路做 UI，最早我有這個想法是 2014 年。

1）為什麼要用 Canvas?

Canvas 是 H5 的畫布元素，即一個 DOM 元素。通過指令碼控制邏輯給畫布上增加文字與影象，而瀏覽器只需要繪製一次形成一幅圖。

只用一個 Canvas DOM 元素，降低 DOM 數量與渲染的複雜度，可以將原來 CPU 密集型變成 GPU 操作。
絕大多數針對 Canvas 是用硬體 GPU 加速渲染。
GPU 的 ALU（計算單元） 比 CPU 要多很多；
而控制運算（邏輯）則可以用 JavaScript 在 CPU 裡做，甚至還可以用 WebWorker 多執行緒處理 CPU 密集型的操作；
從而達到充分利用硬體資源的能力。
Canvas 畫布無論是 JavaScript & H5，還是 native 都有類似的 API。所以：
本地除錯可在瀏覽器裡完成。
最差方案可以用 Canvas UI 跑在瀏覽器裡。
更進一步，可以把瀏覽器 Canvas 介面的反射到用 native 畫布上，以此提高效能。

值得一提的是，騰迅的 X5 核心已經將 egret（白鷺遊戲引擎）與cocos2dx內建，
所以時間線拉長來看，WebView 的畫布功能將會更加強大。

在 2014 年中時，很多人見識過預設置入 cocos2dx 引擎的瀏覽器，用 WebView 玩「捕魚達人」很流暢。

由此說明 Canvas 做 UI 元件可行性還是蠻高的。

2）解決方案.

用遊戲的思路來解決 DOM paint 的問題，業界早就有實驗。
最早實驗的是 zynga 做 angry birds 遊戲的廠家，2010 年寫的 demo scroller：

zynga/scroller · GitHub
Scroller - Canvas

設計、開發一個基於 Canvas 的 UI 框架系統，由於系統相對比較複雜，需接管瀏覽器構建的整個過程：

驗證在實踐環境中的效果，要把原來頁面的 DOM 寫成 canvas，再加上一些調優與比較，工作量相對大，（包括 zynga 也只是實現了一個簡單的 demo 而已）

就暫時擱置了。

最近這陣子在翻 github 與新聞時，我驚喜的發現也有人在做同樣的事了，最後發現 Flipboard 同學們寫的一個 demo：Flipboard

這個 demo 足夠複雜，動畫也足夠多、炫。是用 canvas 來構建整個 UI。

測試過後：

這麼複雜的 demo 在 MI4 以及配置以上效能很好，流暢度無限接近於 native，比較理想。
對比過 G+ 的 Android 應用，G+ 的 App 從動畫上比 Flipboard 提供的的 demo 還「卡」些。
在小米 Note 上的動畫流暢度已秒掉 iPhone 6，非常贊。

按照摩爾定律，可以預計明年 Note 的標配的 CPU 和 GPU 配置會成為主流。

而現在用 canvas UI 框架用在 MI4 以下機器仍然比較慢。而 2015 年 H5 開發 App，對很多公司來說只是 plan B 計劃，大公司甚至 plan B 都不是。所以，如果一定要在純 H5 上搞牛逼動畫，還是再等等吧。

3）佈局系統 css layout.

說回到 Canvas Component framework，回到我上面畫的這張圖：

UI 元件基於「文字」與「影象」。但 framework，除了 UI 元件本身以外，還需要有 Layout，而 css 只適用於瀏覽器本身的 layout 而無法適用於 Canvas 畫布。

要給開發者好且排版可控的方案，那就要開發一個用 JavaScript 實現類似 CSS 的佈局子集的框架。

否則 UI 的元件在畫布上沒有 layout 就無意義。

這個佈局框架實現成本（簡單實現）理論上並不大，大的是在於未來增加新 Feature 並相互組合時與瀏覽器本身有差異，需要有完整的 unit test。
正好最近 facebook 也開源了一個用 JavaScript 寫 css layout 子集的解決方案，實現了：

padding
width
margin
border
flex
position( relative/absolute )

等等。

github 地址：facebook/css-layout · GitHub

這些 css 佈局子集基本能滿足我們前期開發預期。

4）開發框架.

用 css-layout 再加上 UI 管理層，就可以比較清晰的實現出 canvas 的 UI 元件框架了。
那麼，剩下的事就是：

應用開發框架的選擇，如：選擇 React/MVC 框架。
模擬 DOM 層次，即圖層管理。

基於 css-layout + React 基礎上整合而成。

六、Canvas UI 框架不足與風險.

看上去 Canvas 框架這麼牛逼，但有很多缺陷。

對開發人員的要求較高。需要用 JavaScript 實現一些瀏覽器基本的佈局、圖層管理。
第三方使用者學習成本高。不象是用傳統「標籤」就可以實現 UI 在瀏覽器的輸出。
開發者是否買賬，對於框架的開發易用性有「很大」的挑戰。
對開發質量提出新要求。
由於所有的 UI 元件與互動都在畫布 Canvas 裡，所以除錯成本比較高，需要有較為完整的 Logging 與 Debugging 方案。
使用者可用性會受影響。例如：
語音無法識別 Canvas 裡的文字。
無法象 WebView 裡一樣將畫布裡的文字選中並複製出來。

總結.

現在看 FB 開源 react native，不如好好研究 react-canvas 。

169
贊同反對，不會顯示你的姓名
Rix Tox，太不專業了
zhiquan-yu、bitecode、周怒 等人贊同
======= React Native 正式釋出 =======

官網：React Native

沒有參會的我只能等這一天了。雖然慢了點，但還是講講第一體驗吧。

首先一點，React Native真的是完完整整地將React.js的特性搬到了iOS平臺上。所以我最開始說的關於資料流的控制以及Diff Update這些作用在React Native也能得到很好的體現，所以我前面說的竟然沒有跑題。

不過，儘管都是用JavaScript，但是用React做iOS開發跟做網頁開發是完全兩種體驗。在React Native裡你見不到

，但是會經常用到，也就是說我們已經完全脫離了HTML的框框，而是用標記語言的格式寫類似XML風格的JS程式碼，呼叫的都是iOS平臺下的原生元件。App在執行時也不會去跑一個WebView，而是隻執行一個JavaScript Core VM，然後用Objective-C搭建一個Bridge把iOS的各種元件Expose給JS程式碼。React Native實現了一些常用的元件的Bridge可以直接在JS中使用，如果開發者需要使用其他的元件可以自己寫一個Bridge將API Expose給JS VM，所以理論上Native App能做的事情React Native都能做到。

React Native將Flexbox排版移植到了iOS上，也就是說開發者可以不再忍受Constraint-based的Layout Engine，而轉而使用更直觀、更像CSS的Boxed Layout。

JS VM跟iOS的渲染是處於兩個執行緒的，也就是說JS程式碼控制邏輯和Viewer，iOS Framework對Viewer進行渲染。從效率上來看由於JS跟O-C處在兩個執行緒，不會出現因使用VM而帶來的卡頓，相反App的使用體驗十分流暢。對此不太確信的可以嘗試一下Facebook Groups，你會感覺跟用Native App的體驗沒有什麼區別。在開發的過程中JS可以脫離VM來跑，並通過JSON等的序列化來進行通訊，在React Con上的演示就是這樣，他們可以直接用Chrome Developer Tools對App的JS程式碼進行除錯。

可以看出我先前對React Native的預測基本都說中了，它實現了去WebView化，用iOS原生元件作為Viewer的Render Engine，JS程式碼雖然沒有編譯過但是執行效率還不錯。從開發體驗上來看，React Native提供了一套非常完整的開發Workflow，基本上你只要一直跑著iOS Simulator，更新程式碼後在Simulator中Cmd-R一下就能重新整理App，基本不需要進行編譯。我在想，這樣一來其實一定程度上還能做到App內部的自主更新不是嗎？只要把最新的JS程式碼拉下來就能放到VM裡面跑了。就是不知道App Store會不會允許這樣的更新機制。

App的Test也可以完全用JS來寫，而且理論上來說Test的Context與Render環境無關，可以脫離iOS直接在本地的Node.js上跑，這對於程式的除錯來說也是一種便利。開發者可以在非Mac系統下進行Test-driven的開發而不需要去考慮iOS的具體環境。

當然，從文件的各種留白我們可以看出React Native現在還處於非常初期的摸索階段，還有很多iOS Framework下的東西沒有很好地整合進去。但是FB已經向我們Proved the Concept，並且消除了人們對效率和相容性的擔憂。我覺得在現今的基礎上做更深一步的融合是相當迅速的，我相信在接下來的幾個月中我們將看到新一波的Paradigm Shift出現在移動App開發領域。

========== 更新 =========
看到 @rank 把react-canvas都扔出來了我不得不來嘮兩句了。我也是這個星期才在HN上看到的這個專案，實際上這個專案一週前才釋出出來。不得不說這的確是一個很讚的實現，我也見過一些用canvas寫的網頁，對移動端的適應做得非常好，比如這個Legend就設計得很酷炫。

但是，從我目前瞭解到的資訊來看，react-canvas在製作規模化移動端應用方面並不能趕超React Native的勢頭，原因如下：

React Native的目的在於讓原本用WebView做的App去掉DOM渲染層，用更加原生的介面元素和渲染引擎提升效能。但是如果用react-native的話則仍舊沒有脫離WebView，兩者的執行時體積可見一斑。而且這加多一層東西必然對效能有所影響，比如你用Native的方式做Transition Animation，在動畫的實現方面不需要由你的程式碼控制，可以直接使用渲染引擎的自帶動畫，就算有些自定義動畫也不必再JavaScript上面執行，因為React Native已經將JS編譯成了Native的二進位制來執行了，所以又減去一層JS虛擬機器的效率損耗。再看react-native，你要跑canvas就不得不用WebView，不得不使用原本的JS引擎去驅動整個介面，你不得不將所有的控制元件、Layout、Animation全部在JS層面實現一遍，並全權交由JS來控制，這個計算開銷不是一般的大。你如果僅僅為了保留WebView、JavaScript的情況下使用canvas硬體加速而去增加這麼多中間層，實在不是一種理想的趨勢。
由於內容需要在canvas上渲染，那麼有可能會遇到一些寫遊戲的人喜聞樂見的問題，比如CJK字型渲染。還有很多Accessibility方面的硬傷，比如canvas裡面的文字沒法選中、複製或者使用系統的Define功能查詞，也無法相容讀屏程式。在Flipboard的例子中他們的解決這些問題的方法實在是太Dirty了，他們用回了DOM元素，用DOM渲染文字，然後懸浮在canvas上面，這樣使用者就能對文字進行Native的操作。但是這樣的解決方法根本就是在倒退回DOM的開發模式啊好嗎，為了達到上面的效果，他們還得在後臺程式碼構造一個Virtual DOM Tree，實時跟canvas的內容同步，然後更新DOM的內容和style。這樣的做法簡直無法理喻，如果說canvas能靠硬體加速提升效能，你把DOM跟canvas混用那這個效率還能提升多少？再說如果用DOM畫的部分要與canvas上的內容作更復雜的互動，用DOM是根本沒法渲染的。引用react-canvas作者的話來說就是：“pushing the browser beyond its limits that we can make progress in this area.”所以這個專案到底有多Dirty作者本人也是知道的。

相比之下，React Native致力於去掉更多的中間層，只保留一個Flux+React的中心概念，這才是一個合理的發展趨勢。我見到有人說React Native跟react-canvas兩者不衝突，可以用canvas做React Native的渲染引擎。說這話的人還是沒有認識到React Native的目的究竟在哪。我說了React Native在於去掉中間層，你又要用回canvas再加上一個WebView和一堆JavaScript，那React Native的意義何在？就好比喬布斯千方百計把iPhone的厚度減少了一毫米，你帶個套又給人加回去了一樣。

======== 原答案 ========

看了所有的答案，都沒有講清楚React的實質作用在哪。

我上週用純React完成了一個CMS釋出系統的介面框架，資料層僅僅用了Parse的JS庫，但是功能還算完備。中間讀了不少這方面的資料，對Flux + React有了一個較為系統的瞭解。這裡大致總結一下給還沒開始動手寫React的人一點啟發。

要講React的實質作用那一定不能脫離Flux模型。一說到Flux，很多人的第一反應就是那個經常見到的、看起來很複雜的Loop流程圖。我不想一開始就貼那張圖，因為我預設你們都沒真正用過React，那張圖只能讓你們更加不明覺厲。其實瞭解Flux + React最好的方法就是看看官網給的這個視訊，我就把重點摘出來講講吧。

首先，Flux是為了解決MVC模型中資料流向不一致的問題的。視訊中給出了一個非常典型的案例，可以說我以前也被類似的問題折騰了好久。比方說你從服務端拉下來的資料要改變兩個View的內容，比如給未讀訊息的數字提醒+1，然後把訊息放到Chat View中，如果使用者正在看當前的Chat View就把未讀訊息數字-1。這一連串的操作在沒有用React的時候要怎麼寫？她給出的程式碼也是我以前處理類似狀況的方法：

我以前也不是沒想過寫一個MessageManager之類的，類似Flux的Dispatcher一樣的東西去控制這些邏輯然後分別對不同的View進行改動，但是好好想想這不過是一個簡單的資訊接收而已啊，為啥要複雜到專門給一個數字寫一個Dispatcher去做這種事情？所以最後想想還是算了，程式碼醜點就醜點，能用就行，最後我也寫成上面那樣了。但是你要知道，這樣的程式碼寫在非同步程式裡是非常危險的！如果使用者同時在操作，那你的程式碼很可能就會被中斷報錯的。還有，如果後期需要加功能，比如在螢幕側邊再搞個資訊框，那你怎麼知道在哪去加程式碼？你程式的資料交換會像這樣混亂：

怎麼樣？寫非同步MVC的童鞋有沒有感同身受？臉書以前的Chat就是經常因為非同步資料的問題被人黑。比如經常是右上角一個紅色的1，點進去一看啥都沒有，強迫症的怒火你可曉得？

那麼問題來了：如何讓非同步資料像同步資料一樣正確地顯示出來？臉書的攻城獅想到一個絕妙的招式：咱別一個DOM一個DOM的去更新內容了，來一次資料俺們就“重新整理”頁面！是的，就是回到了90年代的那種模式：你想看新郵件？請重新整理頁面！然後服務端把你當前的郵件全部讀一遍，排好序，生成好HTML，然後給你寄過來，你就能看到新郵件啦。Flux就是這麼幹的，只不過現在已經是21世紀了，渲染HTML這種工作不需要服務端也能做，我們也不用真的去重新整理整個網頁，雖說Chat的那個問題的確可以靠重新整理頁面解決掉lol。Flux的（大致）做法是：來新的資料了，好，我把它Merge到客戶端的舊資料中，然後把客戶端存著的所有資料交給一個Render，然後把整個HTML從頭到尾渲染一邊，最後把新的HTML替換掉現有的HTML就好啦！那麼之前那個Chat的程式碼咱就可以這樣寫（我YY的，視訊沒有，也不是React程式碼）
function newMassageHandler(newMessage) {
this.messages.push(newMessage);
this.renderTheWholePage(); // In practice it should be an Action Creator
}
看到沒有？管你有多少個View，你們自個兒去算怎麼渲染吧，handler只管存資料跟提醒渲染。如果哪個View計算完了說，不對，那個Unread Message Number要-1，好，你跟Action Creator說一聲，他會在下一輪渲染前把這個專案加到資料中的。如此一來就不會出現把改動View的程式碼寫到某個Controller中，然後一個Controller又要同時關聯好幾個View的情況，這樣一來整個程式的結構就變得非常清晰了。這時候再看這張圖就容易理解多了：

資料的流向變得非常統一，如果View要對資料做些改動也得等整個View渲染完了在下一輪渲染的時候再改，從而形成一個非常完整的Loop，這對非同步資料的處理是非常有幫助的。

Flux是一個取代MVC的設計模式，而React就是臉書寫的給Flux用的專門做Viewer的框架。由於Flux要將原有的HTML從頭到尾渲染一邊，那麼就不得不考慮一個平滑過渡的問題，因為畢竟我們要講究使用者體驗，不能每次收到資料就真的把原網頁給刪瞭然後重新給使用者畫一個，那使用者還不崩潰啊？React解決這個問題的辦法就是用Virtual DOM，這才是React真正的核心價值。其原理是寫看起來像是DOM的JS程式碼，然後生成ReactDOMElement的物件，而不是真正的DOM，然後把新的Virtual DOM Tree跟使用者正在看的DOM Tree做個Diff，然後用最小的改動量Update整個網頁。對比一下jQuery大概就是這樣：
// jQuery
$(‘‘).text(‘Submit’).on(‘click’, submitHandler);
// Submit

// React without JSX
React.creatElement(‘button’, {onClick: submitHandler}, ‘Submit’);
// Submit

// React with JSX
Submit

可以看到，其實JSX只是React的一個語法糖，這只不過是一門DSL。有些人一看到JSX就說把HTML寫JS裡了，我真是不知道該怎麼評價這種人。ReactDOMButton並不是真的DOM，在執行時只是一個普通的JS Object，我寫成XML形式只是易讀。不用真的DOM當然是因為效率問題，這也是一種優化手段，但是Virtual DOM的好處當然不止這樣，後面會講。

你要是不喜歡JavaScript也沒事，我就不喜歡。知道GitHub的Atom嗎？就是用CoffeeScript + React寫的。它並不是用改過語法的那個看起來就很噁心的coffee-react專案，而是自己寫了一個很簡單的helper來做簡單的Transform。大致的原理是這樣的：
{div, button} = require(‘react’).DOM

div
className: ‘message’
onClick: @messageHandler
‘some messages’
button()

我覺得這樣的寫法真的很簡潔很優雅，而且一想到這寫的根本就不是HTML也沒碰一行JavaScript就覺得很開心啊。不過我是LiveScript黨，有更加簡潔的語法，把Atom的helper改了改現在用在別的專案中用得很方便。

看到這樣的寫法觀眾就應該很清楚地明白了React的原理了吧，它實際上就是把DOM元素全部變成了JS的類，可以直接用JS等價的程式碼呼叫new出來。（實際上是要用一個factory包著才能用的，0.12後把createFactory整合到createElement裡面了所以現在用法上更加簡潔）

但是千萬不要以為React就只是JS世界中的東西，其實它也是受到別的領域的啟發呢。上面那個視訊中後半段詳細介紹了React，其實React這種idea受啟發於遊戲的渲染。有很多遊戲都是資料來了，跟現在的資料Merge一下，然後update資料結構，diff一下老的結構，然後再部分渲染。所以說React其實最重要的還是一種使用Virtual Element描述介面的方式，而因為這種方式容易進行二次計算，所以能夠保證最小幅度的影響使用者體驗，最大幅度地保證資料跟介面的一致。因此React才能夠很輕易地使用在後端，做給Spider渲染HTML的工作。要知道Angular在之前是做不到這一點的，對搜尋引擎的優化竟然要用到PhantomJS！而且這種方式竟然還演變成了收費的服務！簡直讓人咋舌。但是React卻能做到，因為它並不受限於JavaScript，臉書最先用React做後端的時候是PHP的，後來整合Instagram的時候才分離出來寫了開源的JS庫。

所以我覺得React Native的最終形式並不僅僅是把Web做到移動端上，因為那樣根本沒法跟Native的比。而是要把React這種Viewer的架構在Native上實現，把原有的模板式UI重構成Virtual Elements，然後以更加動態的方式渲染。不過就目前的開發進度來看，這個目標還是遙遙無期。

以上。
編輯於 2015-03-27 20 條評論 感謝 分享 收藏 • 沒有幫助 • 舉報 • 作者保留權利

57
贊同反對，不會顯示你的姓名
孫士權，Web Dev / ZJU / http://imsun.net
fall rain、劉子明、知乎使用者 等人贊同
哈哈，大家都不看好它，我倒是覺得它非常不錯。

先說一下傳統的 hybrid app 的一些優劣勢：
優勢：js 可以直接被 native 端執行，也可以和 native code 進行通訊，進而可以呼叫一些 native 提供的介面。 能直接被執行的好處在於可以直接從伺服器上載入並執行 js 程式碼，這點在 iOS 上是 native code 和其他 to objc 的語言都難以做到的。這使我們有了一些更靈活的方法，來完成諸如應用內更新或者開發應用內外掛之類的工作。同時，iOS 和 Android 可以共享一些前端部分的程式碼，使得程式碼能夠更好地重用。

劣勢：介面渲染效率低，多執行緒支援差，GC 問題。在 WebView 中繪製介面、實現動畫的效率都比較低，開銷也比較大。WebWorker 提供的多執行緒在 native 端有很大的侷限，js 在 GC 時也有可能卡 UI。
React Native 的做法非常激進，完全拋棄了 HTML（拋棄了 HTML 不代表拋棄了宣告式），拋棄了 WebView，在 background thread 裡執行 js 並直接使用原生控制元件進行渲染。
這從根本上解決了渲染問題，使得 js 不再只能做 hybrid app，而能做出具有 native behavior 的流暢靠譜的 native app。從這一點上來說 React Native 已經做得相當不錯了，儘管它只實現了 CSS 的子集，但是考慮到 CSS 如此複雜而它又拋棄了使用 webview 渲染，這是可以接受的。

===========
但是，React 的意義絕不在於解決了一些 hybrid app 的痛點。
React 是一個很有野心的專案，它的目標不僅僅是簡單地使前端能用 js 寫 native app，而是希望推廣一個通用的前端構建方案，不論是 Web 前端，還是客戶端前端。
FB 在演講裡說，React 的目標不是 “Write once, run anywhere”，因為不同平臺的差異是客觀存在的，設計風格也各有不同。它要做的，是 “Learn once, write anywhere”。React 裡的 view 不僅可以是 DOM，也可以是 iOS 控制元件或者 Android 控制元件，不論是什麼平臺，都能 “build in React”。

就我看來，前端不只是需要寫網頁，更重要的是要解決屬於前端領域的各種問題。Web 前端和客戶端前端在本質上是一致的，探索前端領域的最佳實踐是一件很有意義的事。
近些年前端比較火，相比於自成體系較為封閉的客戶端前端， Web 前端在前端實踐上的探索或許更多一些。不管是阿里的 Midway 那樣侵入到後端的 UI layer，還是像 React Native 這樣侵入到客戶端前端，我認為都是非常值得稱讚的探索。

至於到底怎麼評價 React Native，我覺得它和 React 一樣贊。

===========
最後附個 FB 關於 React Native 的演講：https://www.youtube.com/watch?v=KVZ-P-ZI6W4
釋出於 2015-01-30 4 條評論 感謝 分享 收藏 • 沒有幫助 • 舉報 • 作者保留權利

12
贊同反對，不會顯示你的姓名
周攀（Henter），http://henter.me
Razer、劉成龍、mfive 等人贊同
henter/ReactNativeRubyChina · GitHub

henter/ReactNativeRubyChina · GitHub
釋出於 2015-04-10 新增評論 感謝 分享 收藏 • 沒有幫助 • 舉報 • 作者保留權利

5
贊同反對，不會顯示你的姓名
林藍東，Cocoa / Ruby Developer
VeraChen、知乎使用者、張一峰 等人贊同
Why React Native Matters · joshaber 這篇文章的觀點比較認同，使用 Javascript 只是一個實現細節：
React lets us write our UIs as a pure function of their state.
This is a big, important idea.
Right now we write UIs by poking at them, manually mutating their properties when something changes, adding and removing views, etc. This is fragile and error-prone. Some tools exist to lessen the pain, but they can only go so far. UIs are big, messy, mutable, stateful bags of sadness.
React let us describe our entire UI for a given state, and then it does the hard work of figuring out what needs to change. It abstracts all the fragile, error-prone code out away from us. We describe what we want, React figures out how to accomplish it.
UIs become composable, immutable, stateless value types. React Native is fantastic news.

實際上 Facebook 在之前也用 Objective-C++ 開發了一套類似現在 React Native 的框架 Components 用於 Facebook for iOS，在 The Functional Programming Concepts in Facebook’s Mobile Apps 這個演講很好地解釋了這種模型的優勢。
釋出於 2015-02-27 2 條評論 感謝 分享 收藏 • 沒有幫助 • 舉報 • 作者保留權利

10
贊同反對，不會顯示你的姓名
老譚，想用React Native寫Android APP的服務端…
知乎使用者、Grace Yang、朱儁 等人贊同
嚐鮮用react native 開發了個簡單的新聞APP （tabalt/ReactNativeNews · GitHub），用著還挺爽的，遇到的問題也基本能在 官方github的issue裡面找到答案。

我覺得最重要的是大大降低了開發native app的門檻與學習成本，像我這樣會點JS的PHP碼農，本身服務端要深入學習的東西就非常非常多，想趕時髦玩玩APP開發，非得要我再去學OC和Swift或者Java麼？

說實話，OC的語法著實不喜歡。有學Swift的功夫，我還不如好好練習下Golang。Java雖然學過，但也早就還給老師了。在各種語言中切換，有時候還真不是一下子能緩過神來。另外除了語言，還得學各種iOS、Android系統相關的特性，還要學兩個平臺下怎麼畫介面。

說白了，我想做的APP就是畫幾個介面而已，這事我用HTML、CSS、JS 幹得已經夠順手了，hybrid的形式，效能又是硬傷。因此React Native剛出來的時候我就在等釋出，一發布就迫不及待的去玩了一把，確實沒有讓我失望。

期待安卓版早日到來~
釋出於 2015-04-07 6 條評論 感謝 分享 收藏 • 沒有幫助 • 舉報 • 作者保留權利

51
贊同反對，不會顯示你的姓名
端木文，JS語言研究，原理探究，應用優化
cp zheng、Zhang oli、張洪亮 等人贊同
我先來答吧。
從很久以前就警告了用HTML5來做App有多不靠譜，不過各種Cloud還是不斷出現。
說到底，HTML5做App的優勢和劣勢都是HTML本身，或者說是DOM，成也蕭何敗也蕭何。
歸功於CSS這個神器，UI製作變得非常簡單而強大。但是卻因為DOM這個東西，每次操作都比Native View慢很多，記憶體開銷也很大。

========分割線========

1. ReactJS在JS圈子裡的口碑在不斷爬升(雖然我沒用過)，元件模式的開發體驗對Native App來說非常適合。
2. React Native宣稱拋棄了DOM，而是純淨的JS Binding。但我還在懷疑他們是打算先用HTML做一次轉換，還是直接修改React的體驗，適配Native View。如果是後者，相信會非常棒。
3. 還需要看看他們用的JS引擎，還有針對Mobile App的優化，比如GC。
4. 從我個人角度看，FB把JS Binding和View Binding這套東西開源出來，比React自身更有意義。

看了@小芋頭君 的回答，繼續說下。

現在確實各方神仙都想用自己的玩具來做本來不屬於他們的領域，比如iOS。

作為一個長期從事JavaScript開發的人，現在因為需求，要做iOS的開發。可能會有很多人想，有很好的前端能力，用HTML5來做會適合。但我沒有這樣做，而是買了一本Swift的書，重新學習一門語言。

PS: 個人不太喜歡OC的語法，Swift對我來說基本可以跳過語法學習。

就如上面說的，我瞭解完全用HTML5做App的危險性：維護成本，可用性，效能等等。有時候，學習相關的東西比用不相關的東西更來的快，更何況Swift很友好。

我想說的是，跟風、傍大款是阻礙程式設計師進步的品質。

還有，別把糖果當成銀彈了。
編輯於 2015-01-30 20 條評論 感謝 分享 收藏 • 沒有幫助 • 舉報 • 作者保留權利

1
贊同反對，不會顯示你的姓名
伏聖文，I love software.
tomisacat 贊同
Titanium (http://www.appcelerator.com/titanium/) 就是和 React Native 一樣的邏輯，用 js 呼叫原生控制元件。

這樣很好，解決了介面體驗問題。

不過也有沒解決的問題。他們無法代替原生的 API，很多效果，開源的控制元件，都要用原生的程式碼來實現。

簡單的 app 沒什麼問題。遇到複雜的 app，還是原生程式碼來的靠譜。
釋出於 2015-01-31 新增評論 感謝 分享 收藏 • 沒有幫助 • 舉報 • 作者保留權利

5
贊同反對，不會顯示你的姓名
Googol Lee，程式設計師
知乎使用者、李飛、知乎使用者 等人贊同
Qt已哭暈在廁所
釋出於 2015-09-25 新增評論 感謝 分享 收藏 • 沒有幫助 • 舉報 • 作者保留權利
Jim Liu，熊掌社前端碼畜，INTJ，各種打自己臉
心情掉線、張亞鵬、吳毅凡 等人贊同
現在趨勢都是宣告式UI，React卻“反其道而行之”，把UI深繫結到JS中去。
然後又嫌程式設計建立控制元件的方式，對於UI的樹狀結構太麻煩了，於是搞出了個JSX。

我就納了悶了，他們團隊究竟是對JS有多執念？

誠然，以現在的前端生態來看，JS的群眾基礎的確是好。
但是用React以後，要儘量保證與傳統DOM的絕緣（下文例1）。從ReactJS的Virtual DOM，到React Native的“No DOM”（引號是因為這詞不是官方的）。對JS群眾而言是個新的挑戰。（而且JSX真的是不怎麼不好用啊）
因為還沒有看到第二天的視訊，具體的一些例項程式碼和技術細節都看不到，但從現在的理解看，它僅僅是用了JS而已，跟前端技術已經沒什麼關係了，東西都要重新學。這方面我會繼續關注後面的視訊。

然後另一方面，因為我不會做Native開發，不知道各種控制元件樣式一般而言是用什麼來定義的，但是如果React Native要搞一套“Native CSS”，這又是個學習成本，同時也是個無底天坑了。
定義樣式這方面，昨天的視訊裡沒有看到，今天的視訊發出來了之後我會再關注一下。

小結：
React Native除了JSX以外，已經和JS的發源地——WEB前端技術沒太大關係了，東西都要重新學。
它並不能提供一個用Web的技術和經驗來開發NativeApp的方式，這一點與Ionic有本質區別。
前端開發者想因此快速做出Native開發，也許做做小樣還行，做出嚴肅的產品，我認為還有距離。

結論：我不認為這是一條給前端轉Native的出路。

上文例1
一些UI控制元件，比如模態框，很常見的實現方式是把模態框從定義的節點裡摘出來，塞進BODY裡面，這樣定位什麼的非常好搞。
氮素，這樣做會破壞真實DOM與Virtual DOM之間的關聯關係，ReactJS會罷工。
例如SemanticUI中的modal元件，需要指定detachable才能讓它不把元素剝離進BODY裡去，SemanticUI的文件中說這樣做會造成渲染獲得更少硬體加速的優化。
這還是人UI元件庫設計的比較周到，如果是要撿著自己的元件庫用，還不知道要踩多少坑。
相比之下，Angular要友好一些，我們寫的UI元件自己接管狀態維護之後，只需要修改scope，然後調用apply，把狀態維護交還給它的digest迴圈就行了。具體就不展開討論了。
釋出於 2015-01-30 6 條評論 感謝 分享 收藏 • 沒有幫助 • 舉報 • 作者保留權利

2
贊同反對，不會顯示你的姓名
Alsey，軟體技術工作者
楊東、Daneel Olivaw 贊同
react native做了兩件事，一件是react，一件是native。
react的核心是元件化，元件化的優勢是複用和視覺化開發。這樣就很容易形成類似visual studio這樣強大的介面開發工具。其實，react走元件化的路線更多是為了提供抽象的介面層。有了抽象的介面層就為後續實現大一統的開發環境邁出了第一步。
native可以稱其為小型虛擬機器，或是實時直譯器。它的出現就是對底層native的遮蔽。因為沒有類似於java的編譯步驟，所以就是write once， run anywhere，本質上和java虛擬機器是一樣/類似的。
就此看來react team的目標肯定是做一個大一統的開發平臺，對不同的作業系統，web和native相容幷包，那麼react native是其中的第二步。
釋出於 2015-02-04 新增評論 感謝 分享 收藏 • 沒有幫助 • 舉報 • 作者保留權利

2
贊同反對，不會顯示你的姓名
張開宇，RoR貢獻者，Emacs貢獻者
孤獨惟者、知乎使用者 贊同
React Native的功能很強大。最重要的，學習一種開發方式，可以開發各種平臺的前端。

它跟React Native有不同的理念。CocoaBean志在一次程式碼，多次執行，並且程式碼風格跟本地開發MVC一模一樣，適合小團隊創業，尤其是新聞評論分享app和展示app。