- 原文地址：Sunsetting React Native
- 原文作者：Gabriel Peal
- 譯文出自：掘金翻譯計劃
- 本文永久連結：github.com/xitu/gold-m…
- 譯者：ALVINYEH
- 校對者：DateBro
React Native 退役
由於各種技術和組織方面的問題，我們將停止使用 React Native，並將致力於讓原生體驗更好。
這是系列部落格文章中的第四篇，本文將會概述使用 React Native 的經驗，以及 Airbnb 移動端接下來要做的事情。 今天，我們路在何方？
儘管很多團隊都依賴 React Native，計劃在可預見的將來投入使用，但我們最終無法實現我們原來的目標。此外，還有一些我們無法克服的技術和組織挑戰，使繼續投入使用 React Native 變得更加困難。
因此，我們要勇往直前，Airbnb 正式停止使用 React Native，並將我們所有的精力重新投入原生。
未能實現我們的目標
迭代速度需要更快
當 React Native 能按預期工作時，工程師能夠以無與倫比的速度進行迭代。但是，我們在本系列部落格中所概述的眾多技術和組織的問題，增加了許多專案的挫折和意外耽擱的時間。
維護質量標準
最近，隨著 React Native 越來越成熟，我們積累了更多專業知識，現在能夠完成許多當初不確定的事情。我們構建了共享元素轉換、滾動視差、並且能夠顯著地提高過去經常丟幀的一些螢幕的效能。然而，諸如初始化和非同步優先渲染等一些技術挑戰，滿足某些目標具有挑戰性。內部和外部缺乏資源使得這更加困難。
只編寫一次程式碼而不是兩次
儘管 React Native 功能中的程式碼幾乎可以在不同平臺共享，但我們的應用中也只有一小部分是 React Native。此外，為了讓產品工程師能夠有效地工作，還需要大量橋接基礎架構。因此，我們在三個平臺（而不是兩個平臺）上支援程式碼。我們看到了移動端和 Web 之間程式碼共享的潛力，並且能夠共享一些 npm 包，但除此之外，它從未以有意義的方式實現。
改善開發者體驗
React Native 的開發人員經驗非常不同。在某些方面，例如構建時間，情況要好得多。但是，在其他方面，比如除錯，情況比較糟糕。本系列的第 2 部分列舉了具體細節。
退役計劃
由於無法實現我們的特定目標，因此我們做了一個艱難的決定 —— React Native 不再適合我們了。我們目前正在與團隊合作制定健康的過渡計劃。我們已經停止了所有新的 React Native 功能，並計劃在今年年底之前，將大多數最高流量的檢視頁面轉換為原生編寫。這得到了一些即將開始的預定重新設計的幫助。我們的原生基礎架構團隊將支援到 2018 年的 React Native。在 2019 年，我們將開始降低支援並減少一些 React Native 開銷，例如啟動時的初始化執行時。
在 Airbnb，我們是開源軟體的堅定信徒。我們積極使用和促進世界各地的許多開源專案，並且也開放了一些我們的 React Native工作。由於我們已經不再使用 React Native 了，我們無法像社群一樣維護 React Native 的功能。為了讓社群變得更好，我們將把一些 React Native 開源工作遷移到 react-native-community，我們已經開始使用 react-native-maps，並即將使用 native-navigation 和 lottie-react-native。
這並不全是壞事
儘管無法繼續通過 React Native 來實現我們的目標，但使用 React Native 的工程師都有不錯的體驗。在這些工程師中：
- 60% 的人認為他們的體驗是令人驚訝的。
- 20% 的人認為還不錯。
- 15% 的人認為比較糟糕。
- 5% 的人表現出強烈否定的態度。
如果有機會，63％ 的工程師會再次選擇 React Native，74％ 的工程師會考慮將 React Native 用於新專案。但值得注意的是，這些結果中存在固有的選擇偏倚，因為它只調查選擇使用 React Native 的人。
這些工程師在 220 個頁面上編寫了 80,000 行產品程式碼以及 40,000 行 Javascript 基礎結構。作為參考，我們在每個原生平臺上分別有，大約 10 倍的程式碼量和 4 倍的頁面數量。
React Native 正在走向成熟
這一系列的部落格真實反映出了，我們在現階段使用 React Native 的經驗。但是，Facebook 和更開放的 React Native 社群致力於適合混合應用的 React Native。React Native 正在以前所未有的速度向前發展。去年有超過 2500 個 commit，Facebook 剛剛宣佈他們正在解決我們正面臨的一些技術挑戰。即使我們不再使用 React Native，我們也很高興能夠繼續關注這些發展，因為 React Native 的技術優勢為世界各地使用我們產品的人們，帶來了實實在在的成功。
一些思考
我們將 React Native 整合到大型現有應用中，並持續以非常快的速度迭代。我們遇到的許多困難，都是由於採用了混合模型方法。但是，我們的規模能夠承擔並解決小公司可能沒有時間解決的一些難題。想讓 React Native 與原生無縫互相協作是有可能的，但很有挑戰性。每個使用 React Native 的公司都會有一種由他們的團隊組成、現有應用、產品需求和 React Native 成熟度確定的獨特體驗。
當一切齊頭並進時，React Native 能匹配許多功能所做的工作、迭代速度、質量和開發人員的體驗，甚至超越了我們的所有目標和期望。有時候，真的覺得我們即將改變移動開發的遊戲規則。儘管這些經歷令人備受鼓舞，但當我們將積極情緒與工程組織的痛點，以及當前的需求和資源相平衡時，我們認為它已不適合我們了。
決定是否使用新平臺是一項重大的決策，這完全取決於你團隊的獨特因素。我們放棄使用的經歷和原因，可能會不適用於你的團隊。事實上，許多公司現今仍在繼續成功使用它，對於其他公司來說，它可能仍然是多數公司的最佳選擇。
雖然我們從未停止過使用原生，但 React Native 退役後可以騰出更多資源，使原生化比以往更好。請繼續閱讀本系列的下一部分，一起了解學習原生的新功能。
這是系列部落格文章的第四部分，重點講述了我們使用 React Native 的經驗，以及 Airbnb 移動端接下來要做的事情。
在此感謝 Laura Kelly。
如果發現譯文存在錯誤或其他需要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可獲得相應獎勵積分。文章開頭的 本文永久連結 即為本文在 GitHub 上的 MarkDown 連結。
掘金翻譯計劃 是一個翻譯優質網際網路技術文章的社群，文章來源為 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。