【译】 Airbnb 下线 ReactNative

Medium 原文 Sunsetting React Native

由于很多技术上以及组织架构上的问题,我们(Airbnb)决定全面下线 ReactNative ,会把所有的研发精力都投入到让 Native 原生开发上,希望原生效果更加完美,令人惊艳。

这是我们一系列文章中的第四篇,整个系列文章打算重点介绍我们在 React Native 方面的经验以及Airbnb 的移动端 App 下一步该怎么走

尽管很多公司和团队在项目中都使用了 ReactNative 并且在未来可预见的功能与需求中还会继续使用它,但我们最终还是无法实现我们最初定下的目标。此外,还有一些来自于技术上与团队组织上无法克服的困难,使得继续投资 ReactNative 已经变成了一个挑战。

因此,我们决定向前看,我们正在下线 Airbnb 中的 ReactNative,并且把所有的这些努力都重新投资在原生开发上。

ReactNative 没有实现的目标

快速迭代

当 ReactNative 按着预期进行工作的时候,我们的研发工程师确实能够以无与伦比的速度进行功能迭代。然而我们还是发现有很多技术上或者组织上的问题,会给项目增加很大的挫败感以及带来意外的项目延期。

保证质量底线

最近,随着 ReactNative 的逐渐成熟,我们也积累了更多的经验,以前很多做不到的事情现在都能实现。我们实现了共享元素转场,视差效果,并且能把过去丢帧的模块的性能显著提高。然而,在一些诸如初始化和异步首屏渲染等技术问题上,想达到某些预期目标很难。并且内部以及外部资源的匮乏也让事情变得更加艰难。

一次开发适配两/三个平台

尽管使用 ReactNative 代码开发出来的功能,几乎就是跨平台共享的,但我们的 App 中,只有一小部分是 ReactNative 的。除此之外,还需要进行大量的桥接基础设施建设,才能让 ReactNative 的工程师能够顺利有效的进行工作。因此我们尝试在三个平台上共享代码,而不是只关注移动端2个平台。理论上我们确实看到了在 Web 上与 App 上共用几个 npm 包有很大的潜力,但我们并没有实质上的的进展。

提高开发体验

使用 ReactNative 的开发人员的开发体验非常的混乱,不好衡量。有些方面,比如构建时间,这种动态化的热重载的开发模式要好很多。然而其他方面,比如调试就变得非常的低效。详细的细节在第二篇文章就提过了。

下线计划

因为我们无法实现当初定下的目标,我们认为 ReactNative 已经不适合我们了。我们正在准备一套稳妥健康的迁移方案。我们已经停止了所有 ReactNative 的新功能开发,并且计划在今年年底完成最主要的高流量的功能模块,从 ReactNative 迁移回原生开发。这件事情也得益于有些功能模块正打算重新设计。我们的基础架构团队在2018年继续对 ReactNative 提供支持,但到了2019年将要降低支持,并着手减少一些 ReactNative 资源分配,比如 RN runtime 启动初始化资源等。

在 Airbnb 我们是开源软件的坚定支持者,我们很积极的为很多全世界的开源项目做了大量贡献,并且也开源了我们在 ReactNative 上的一些工作。但由于我们已经决定下线 ReactNative ,我们也没有经历继续维护这些 ReactNative Repos 开源项目。为了能够更好的回报社区,我们决定把我们的一些 ReactNative Repos 开源项目,迁移到 react-native-community 社区。我们已经开始迁移 react-native-maps 这个项目,并且未来也会逐渐迁移 native-navigation 和 lottie-react-native 这两个项目。

ReactNative 也不是所有人都觉得很差

尽管 ReactNative 达不到我们的目标,但使用 ReactNative 的人中也有很多人持肯定态度:

  • 60%的人觉得他们使用 ReactNative 的经历十分的美妙,十分肯定。
  • 20%的人觉得他们使用 ReactNative 的经历还是不错的,略微肯定。
  • 15%的人觉得他们使用 ReactNative 的经历不太好,略微否定。
  • 5%的人觉得他们使用 ReactNative 的经历非常的难受,强烈否定。

ReactNative 还在发展成熟

我们发的这一系列 5 篇文章,反映了我们今天使用 ReactNative 的经验,但包括 Facebook 在内,并且还有更多的 ReactNative 社区,都在致力于让 ReactNative 实现更好更强大的混合开发体验。ReactNative 也在以前所未有的速度更快的发展着,仅去年就有 2500 次提交。并且 Facebook 刚宣布他们正在解决我们曾经遇到过的这些技术难题。即使我们不在使用 ReactNative ,我们还是很高兴能持续关注 ReactNative 的发展。因为 ReactNative 这项技术实实在在为全世界使用我们产品的人们带来过收益。

其他要说的

我们将 ReactNative 整合到现有的大型 App 项目中去,还保持着很快的迭代速度。在这过程中遇到的很多问题其实是由于我们采用的这种混合的开发模式导致的。并且由于我们的公司规模,可以让我们去解决一些对小公司来说没有时间解决的相关技术难题。这种混合开发的模式下,让 ReactNative 与原生无缝协作与融合在一起是绝对可行的,但也是一项很有挑战的事情。每个使用 ReactNative 的公司都有他们自己的使用体验,这取决于他们的团队组成,现有 App 架构,产品需求,以及使用的 ReactNative 的版本成熟度等因素。

也许有一天 ReactNative 这个技术发展了,有了很多新的功能,有了更快的迭代速度,有了更稳定的质量,更好的开发者体验,甚至是满足了我们大家所有的目标与期望。有时候会有一种我们正处在移动开发这个行业正在发生变革的边缘的感觉。这些技术发展相关的感受其实十分令人激动与兴奋,但现在我们权衡了这些积极感受与业务痛点以及当前需求资源的平衡,我们还是觉得 ReactNative 不适合我们了。

决定是否使用新框架是一个重大决定,完全取决于您的团队独有的因素。我们的经历和选择放弃的原因可能不适用于您的团队。事实上,许多公司今天仍在继续成功使用它,它可能仍然是许多公司的最佳选择。

尽管我们从未停止对原生开发的投入,但下线 ReactNative 还是可以释放出很多资源来让原生开发做的更好,可以阅读下一篇文章,来看看我们将在原生开发上,投入哪些新的东西。

文章索引