[譯] React Native vs. Cordova、PhoneGap、Ionic，等等
原文連結: ofollow,noindex">learnreact.design/2018/02/14/…
喜歡理由: 文筆生動 通俗易懂
特別鳴謝: 原作者Linton Ye 的傾情校對
系列部落格: 用通俗的語言和塗鴉來解釋 React 術語
- 圖解 React
- 圖解 React Native
- 元件、Props 和 State
- 深入理解 Props 和 State
- React Native vs. Cordova、PhoneGap、Ionic，等等 (本文)
在前面的文章中，我曾說過 React Native 很棒，因為它能讓我們使用原生 UI 來開發應用。React Native 應用的使用者體驗要比使用 WebView UI 的好很多。但是，“原生”的真正含義到底是什麼呢？什麼是 WebView UI ？什麼原生 UI 比 WebView UI 好呢？React Native 相比於其他移動端框架 (比如 PhoneGap、Cordova 和 Ionic) 又如何呢？
現在我們來深入這些問題。坐穩了！(譯註: 老司機口頭禪)
學習目標
當你讀完本文後，希望你能重新回到這裡，並能夠輕鬆回答以下問題:
- 什麼是原生應用？
- 什麼是 WebView UI ？
- 更原生化的框架的優勢和劣勢分別是什麼？原生化更少的框架呢？
- React Native 與 Cordova 相比如何？
到底什麼才是“原生”應用？
要理解“原生化” (nativeness) 的真正含義，先看下面:
我是黑客帝國 (The Matrix) 的死忠粉，你呢？在影片中，我們所認知的現實實際上是一個模擬世界。有線索提示，即使是錫安，最後一座人類的自由之城，也是模擬出來的。多層模擬現實的想法一直讓我為之著迷，一個虛擬世界作為模擬執行在另一個虛擬世界中，而這個虛擬世界又執行在第三個世界中。
這與計算機 (或手機) 的軟體架構十分相像。
軟體是關於如何操作大量電晶體和電路 (兩者統稱為硬體) 的指令的集合。直接執行在硬體上的原始指令對我們人類來說是幾乎無法理解的, 特別是考慮到當今計算機的複雜性和規模。
要使得軟體可以理解和操作的話，電腦科學家將其劃分為多個層，這些層均是由框架構成的，每個框架都執行在另一個框架之上。在所有框架中，越接近硬體的框架，我們就說它更“原生”。
所以，一個應用的“原生化”只是一個相對的概念。嚴格來說，我們無法說一個應用本身是否是原生的。我們只能說，相比於另一個應用，它是更原生的。舉個例子，你可以使用 C++ 、Java (或 Kotlin) 或 Cordova 來開發安卓應用。C++ 寫的應用是最原生的，而 Cordova 寫的應用是最不原生的。Java/Kotlin 寫的應用介於兩者之間。
更原生的應用的好處是什麼？
原生化多或少都有各自的好處。接近金屬意味著更多的自由，而更多的模擬會讓你更為舒適。(求助: metal 是指黑客帝國裡的矩陣嗎？還是指硬體？)
通常，更原生的框架中的程式能夠獲取更多的硬體功能，以及使用硬體更加自由。由於在不同語言之間進行模擬和翻譯的開銷較低，通常它的執行效率更高。但現實是殘酷的，它的程式碼通常更難編寫和理解。
另一方面，對於原生化更少的框架來說，通常編寫程式碼更為簡單。編碼語言也更容易理解和簡潔(需要的程式碼少)。它的詞彙更接近與我們人類的自然語言。它不需要我們十分了解硬體的構成以及它在幕後的工作方式。還有一個額外的好處，原生化較少的框架中的程式通常更具可移植性，程式可以在完全不同的硬體平臺上執行而無需修改，因為它的詞彙和底層概念不包含任何特定於原始硬體的內容。但是，這一切便利的程式碼就是通常會犧牲一些效率和自由度。
移動端框架陣營
在 React Native 出現之前，移動端框架一般分為兩個陣營。
首先是原生陣營，例如安卓的 Java/Kotlin 和 IOS 的 Objective-C/Swift 。此陣營中的應用速度都很快，並且可以使用豐富的硬體功能。使用者介面是針對目標平臺(安卓或 IOS)的定製的，因此使用起來是流暢且愉悅的。但是，所有這些好處都被限制在一個平臺上了。要開發應用的話，需要學習不同的框架，這使得學習成本翻倍，甚至更高，在這點上遠高於其他數百萬的 Web 開發人員。
另外一個陣營就是以 Cordova/PhoneGap 和 Ionic 為代表的。這些框架可以讓 Web 開發人員使用他們已經具備的 HTML、CSS 和 JavaScript 技能來開發應用。這些應用可以同時執行在安卓和 IOS 平臺上(還可以有更多平臺)。但是，相比於原生應用，這類應用會沒有那麼流暢，能訪問的硬體功能也有限。最重要的是，這些應用的使用者介面太爛了！因為這些框架使用的 WebView 來渲染 UI，所以我們將其稱之為 WebView 框架。
WebView 框架是在原生框架之上構建的。我們可以將前者視為執行在後者內部的模擬世界中。這正是他們有上述的好處和限制的原因所在。
為什麼我們不能集兩者之優勢，同時又避免它們的不足呢？這正是 React Native 要做的事。
React Native 代表的是移動端框架的第三陣營。它的 UI 層要比 WebView 框架更原生，而其餘部分處於模擬層，以實現其易用性。
React Native 要比 WebView UI 原生得多
像 Cordova 這樣的框架可以使用 Web 技術來開發移動 UI 。它們是如何做到的呢？它們在每個應用中都內嵌了 Web 瀏覽器，並美名其曰 WebView！你在 UI 中看到的所有，包括按鈕、選單和動畫，都是在瀏覽器的網頁中執行的。以模擬的角度來看，Cordova 應用的 UI 就是執行在 Web 瀏覽器中的模擬世界，而瀏覽器又是執行在原生框架裡的另一個模擬世界。
相比之下，React Native 的 UI 要比 WebView 框架低一個層級，它直接執行在原生框架裡。
這種架構奠定了 React Native UI 的優勢。React Native 直接使用了原生 UI 元件，而 WebView 框架是使用 HTML/CSS 的 Web UI 來模擬原生 UI 。真和假，你更喜歡哪個？
根據經驗，識別出一個應用是否是使用 WebView 框架開發的並不難。通過一些小測試，比如滾動加速、鍵盤操作、導航和 UI 的流暢性。如果這些操作達不到原生般的效果，那麼累積後的效果將導致糟糕的使用者體驗。
React Native 使用 JavaScript 來讓開發變得簡單
另一方面，React Native 還可以讓我們使用 JavaScript 來編寫應用，同時使用類似於 HTML 和 CSS 的語法來開發 UI 。這無疑降低了 Web 設計師和開發人員的門檻。
當需要時，React Native 還提供了一種滲透到原生框架的方法，以實現我們希望在應用中實現的任何原生功能。這有點像在黑客帝國中打電話。
所以 WebView 框架一無是處嘍？
不，當然不是。舉個例子，如果你已經有了 Web 應用，並且想盡快地釋出到應用商店中。您願意犧牲使用者體驗以縮短面向使用者的時間。
另一種情況是，如果你的應用中並沒有太多互動相關的東西，那麼把它放入 WebView 中也並沒那麼糟。
但是，如果應用的使用者體驗重要的話，如果應用具有一定的互動性的話，像接受使用者輸入、拖拽、滑動頁面等，那麼決定應該考慮使用 React Native 。因為使用 WebView UI 來模擬原生 UI 是下下策。