作者 | Standard Notes
譯者 | 馬可薇
策劃 | 丁曉昀
多年以來，Standard Notes 的代碼庫不斷髮展：在 2016 年的首次發佈時，我們擁有三個代碼庫，即網頁應用（其中包括我們的 Electron 桌面應用）、原生 Swift iOS 應用，以及原生 Kotlin 安卓應用。這種形式很快便無以爲繼，跨三個平臺的問題修復就已經很難協調了，在此基礎上再要新增功能？天方夜譚。我們不得不給應用打上“簡約風”的標籤，因爲我們真的沒辦法再做別的了。不過諷刺的是，這個標籤可能真的有點道理。
從三到二的代碼庫
我們在 2017 年將移動端應用過渡到了 React Native，讓代碼庫數量從三降爲二。在那段時間我們彷彿是到了仙境，無論什麼時候想加新功能，比如圖片和文字加密功能，我們都只用寫兩遍代碼，是不是很美好？不盡然。的確，最大化代碼庫的使用讓我們不再需要重寫關鍵業務邏輯，但這種方式也會有侷限：我們需要重寫兩遍底層加密的 C 函數，因爲我們的網頁端和移動端的加密庫不通用。
但即使最大化地榨乾了業務邏輯，對於小團隊來說，協調兩套代碼庫中的新增 UI 功能也是雙倍的工作量。移動端和網頁端所遇到的問題不同，工作的時間線也不同，一個僅出現在移動端的問題可能會需要兩天時間來修復，導致移動端和網頁端雙方都長期處於不同的波段上。同步網頁端和移動端的新功能永遠是個難題，而一般來說，網頁端的開發速度總會快與移動端，從而導致移動端總是處於落後狀態。由此導致的後果是，無論是移動還是網頁，我們都看不到明顯的新功能出現勢頭。
React Native 的構建永遠會需要大量第三方庫。其本身的程序包便是個品種獨特的龐然大物，因爲 React Native 包的作者本人也是會需要重寫兩遍代碼的人：一次寫 iOS 的代碼，一次寫安卓的代碼（當然也包括 JavaScript 的 wrapper）。其後果就是大量庫的棄用和穩定性問題的急劇出現。另外，保持自己的包與最新版本的 React Native 同步這件事是想想就頭疼，畢竟 React Native 是出了名的難以保持更新。
終於有一天我們受夠了折磨，兩個代碼庫對我們來說還是太多了。要是能只寫一遍代碼該多好，我們的發佈速度能有多快，所有的質量和關注中心都將集中在一處，我們再也不用馬後炮似地對待移動設備，再也不用爲將新功能額外同步給移動端而發愁，再也不會因爲移動端新增功能的困難重重和不切實際的雙倍工作量而被迫放棄想要的功能。在一個代碼庫里加功能就足夠了。
一個代碼庫
在我們完成兩到一的代碼庫遷移後，我們只恨沒早點這麼做。如今的 Standard Notes 只有一個代碼庫，移動端應用程序變成了網頁程序的一部分，區別在於後者可以訪問原生的移動功能，且運行效果比我們想象中要好很多。目前網頁端功能已經可以一比一同步移動端應用，這在我們的舊配置中是完全不可能達成的，不僅如此，網頁端應用也能訪問到本地原生移動端鑰匙串（keychain）、生物識別、本地存儲、攝像頭，等等。
從 React Native 中移除 React
我們的遷移過程其實很簡單，主要在於橋接網頁環境和移動環境的落差。我們全新的移動應用依舊使用 React Native，但只包含用於渲染網頁視圖（webview）的函數這一個組件。網頁視圖通過 postMessage 進行網頁與移動環境之間的消息傳遞，當網頁端試圖訪問設備的鑰匙串時，其會向原生環境發送一則消息，而原生環境則回覆以一個原始值。
但無論原生環境還是網頁環境都完全無需擔心“消息傳遞”的細節，這些不過只是函數調用。網頁環境不用知道自己的函數調用會在後臺被轉換爲 postMessage 調用，就像使用其他異步函數調用一樣，網頁端只用 await 回覆即可。我們不想在文章裏包含太多技術細節，但從更高層次來說，我們的架構中所包含的各個平臺都僅僅需要在應用示例中提供一個叫 DeviceInterface 的類，這個接口讓應用程序可以在任何平臺上運行，哪怕是命令行都行。設備接口會提供對如數據庫、鑰匙串、攝像頭等設備 API 的訪問。
構建移動應用的實用方法
別誤會，React Native 還是有很多閃光點的，它的社區和包的生態系統非常活躍，甚至可能是超越其他生態系統的活躍度。但如果你也遇到了兩個代碼庫對小型團隊而言嫌多的情況，不妨試試這個方法。不用把網頁應用的 UI 完全推翻重寫成 React Native，只需要利用 React Native 當作橋樑，從網頁應用的核心訪問本地系統功能。因此，我們的新移動應用預計會比一直在喫半原生應用尾氣的舊版強上無數倍，自己試試吧！
如果你想立刻動手，歡迎採用與我們類似的方法，或者也可以參考 Capacitor 之類的庫，不過後者沒有像是 React Native 這種擁有豐富第三方包的生態系統。
原文鏈接：
https://standardnotes.com/blog/react-native-is-not-the-future