原文地址：ionicframework.com/blog/ask-a-…
原文作者：
发布时间：2020年7月23日
大家好，我是Eric Horodyski，是Ionic这里最新的解决方案架构师。在加入这里的团队之前，我之前五年的职业生涯是作为一名首席开发者，构建了几十个混合移动应用，有些是用React Native，有些是用Ionic。
在我担任Lead Developer的这些年里，我的职业圈内对混合移动开发的兴趣持续增长。有些人认为它是他们的组织进入移动领域的一种经济实惠的方式，有些人则认为它是整合现有代码库的一种方式。不管原因是什么，我的参与是从这个问题出现时开始的。"我们应该选择Ionic还是React Native？"
这是一个很重要的问题--在这个决定上要投入时间和金钱。可以说同样重要的是，这个决定为开发团队设定了方向。不幸的是，在我看来，为这个问题所写的材料质量很差。在对这个话题进行深入研究后，我发现大多数文章会将React Native和Ionic以拳击比赛的方式对立起来：两个框架进入，一个框架离开。
坚持用战斗的比喻，这些文章提供了一个tale-of-the-tape；比较GitHub明星和帧率等差异。我还没有读到过一篇文章，比较框架在客户需求、项目复杂度和组织需求上的差异；这些因素的权重远大于每秒打60帧。
老实说，Ionic和React Native都能让开发者构建出漂亮的、性能优异的移动应用，这让作为首席开发者的我不得不做出一个非常困难的选择。我不能在这里给你一个 "一刀切 "的答案--如果这就是你想通过这篇文章寻找的东西，你可以放弃，我会理解的。我可以提供在这两个项目中领导项目所获得的教训和经验的见解，我希望我第一次不得不做出这个决定时就知道。
误区
老实说，我还没有读过一篇比较文章，没有把React Native定位为更好的框架；它利用了实际的原生组件，所以性能更好，而且它创建了标准的原生项目，所以你可以更容易地把JavaScript和原生代码混搭在一起。
在我开发混合移动应用的第一年左右，我严格使用Ionic和Cordova。当时机成熟时，我很兴奋地挖掘React Native，但很快就意识到，比较件有点误导人。
性能与框架无关
一些框架对比文章中附带的基准，展示了React Native是性能更强的平台。虽然这在理论上可能是正确的，但这并不意味着在实践中总是适用。抛开一些复杂度，再撒上写得不好的代码，你很容易就能构建出一个性能不佳的React Native项目，而且比Ionic项目还慢。
举个例子，我参与了两个项目（每个框架都有一个），它们不约而同地有一个类似的需求：引导用户完成一个多步骤的表单提交过程。React Native项目在加载每一步时都有0.2秒的明显滞后。另一方面，Ionic项目的导航速度快如闪电，尽管它是更复杂的实现。
稍微调试了一下，发现我们用React Native导航的库是原因所在--它们只是性能不如Angular的路由器。
桥接Native代码非常相似
对比件让我相信，将原生代码桥接到React Native的过程是一种更优越的体验，而且在React Native项目中引入原生移动开发者会比Ionic项目更容易。
事实证明，这两个框架的流程基本相同。有一个标准的接口来应用你的原生代码，用于将原生函数暴露给你的JavaScript项目。对项目和应用的启动逻辑进行配置修改。
将Capacitor扔进混合--它将原生项目添加为源码工件--你可以将原生代码以与React Native完全相同的方式桥接到你的Ionic应用中，无论你是打算为社区构建一个插件，还是将你的原生代码保持在本地的源码控制中。
设计
作为一名首席开发人员，你的核心职责之一就是估算设计应用所需的时间和精力。你的估算归根结底是成本，所以了解Ionic与React Native在设计和造型上的核心差异是极其重要的。
最重要的是，React Native组件将渲染它们的原生等价物，没有预制的样式选项可供选择。如果你的项目是为了尽可能地匹配本地平台的样式，那么使用React Native就有很大的好处。Ionic提供了自适应风格，每个Ionic组件都会根据应用运行的平台调整其外观。然而，一些Ionic组件，如数据选取器，并不完全匹配它们的原生对应物。
反过来说，如果你的项目有一个设计系统需要遵守和/或应该在不同平台之间看起来一致，根据我的经验，Ionic在平台之间标准化设计所花费的时间要少得多。
同样重要的是，React Native集成了CSS的一个子集。从表面上看，与CSS子集一起工作似乎无关紧要，但我很快就发现，准确地确定特定设计的工作范围和可行性是很有挑战性的。响应式设计范式，如媒体查询，在React Native中并不容易获得。这导致了与一个只为基于Web的混合应用程序设计的设计团队合作的经历特别紧张--他们很难理解要适应他们所针对的所有设备尺寸需要多大的额外努力。
最近，可访问性（一种特别考虑残疾人需求的设计过程）已经成为移动设计的一个重要方面。移动开发社区已经看到因不可访问的应用程序而提起的诉讼激增。不幸的是，没有与网页内容可访问性指南(WCAG)相对应的移动设备，该指南为满足可访问性合规性要求提供了明确和定义的规则。
值得庆幸的是，React Native和Ionic都为您的无障碍性成功做了准备。由于Ionic是基于Web的，您可以遵守WCAG指南。React Native有一个强大的可访问性API（这是我最喜欢的框架之一），但由于没有任何标准化的移动端可访问性合规性要求，我发现自己在与法律部门的人合作时，他们会解释说，在Ionic应用中实现的一些准则不适用于React Native。
原生集成
当涉及到整合原生功能时，React Native和Ionic都有相当直接的流程--前提是你使用Capacitor来构建你的混合应用。React Native和Capacitor都遵循同样的流程。
- 编写实现特定接口的本地代码。
- 编写JavaScript代码，调用挂钩到你的本地代码。
然而，Capacitor是一个相对较新的原生桥，Ionic可以利用它。在我担任首席开发人员的大部分时间里，Apache Cordova是唯一可用的本地桥选项。
我总是发现很难将定制的原生代码融入到我所领导的Cordova应用中。Cordova应用使用的原生代码必须作为插件安装，是一个独立的项目。这将意味着我的团队不再只是专注于为一个应用构建一个项目，额外的项目也被创建为构建Cordova插件。通常情况下，这意味着我们会在没有测试正在构建的自定义原生代码如何与正在构建的实际应用进行交互的情况下进行数周的工作。
Capacitor和React Native利用平台项目作为源构件，简化了将原生代码桥接到应用程序中的过程，是的，允许你在与应用程序相同的项目中测试你的自定义原生代码。我认为这是一个重要的收获，因为大多数比较文章都没有提到 Capacitor。
有些移动应用是为了增强特定的原生集成而构建的，比如Snapchat，它的体验是围绕（或者说是在）设备的摄像头而构建的。我领导了一个项目，它有一个Snapchat式的体验，在React Native中构建是非常琐碎的。使用设备摄像头作为我的应用程序的背景，就像添加一个社区插件一样简单，它为我现有的组件池提供了一个React Native组件，还有按钮和输入字段。诚然，我还没有用Ionic构建这种类型的体验--既没有用Capacitor，也没有用Cordova--所以我无法评论相比之下这有多难。然而，我知道有一种社区方法，即在托管你的应用程序的WebView上打一个 "洞"，暴露出底层的本地控件（如地图）--这听起来像一个典型的混合开发者的较大任务。
不过最重要的是，Ionic和React Native都死于社区支持。在我的整个经验中，我遇到的一个不幸的趋势是，当涉及到原生集成时，大多数混合开发团队依靠开源社区来提供即插即用的解决方案。这两个社区都是活跃而健康的--但这并不意味着在项目与社区深度交融后，社区解决方案不会被抛弃。
幸运的是，React Native和Ionic都有解决这个问题的方法。Expo是React Native核心团队之外的一家公司，它提供了一个包括健康的原生集成的API。Ionic除了支持和维护Ionic框架外，还为Capacitor和Cordova提供企业插件和解决方案，并提供支持、咨询服务和SLA。
总结
我喜欢Ionic和React Native，并且非常享受作为首席开发者与这两者的合作。在混合移动生态系统中，这两者肯定有足够的空间。竞争推动了创新--这最终会让整个开发者受益。Capacitor就是一个很好的例子，它为Ionic开发者提供了与React Native相当的工具，并解决了很多与Cordova合作时的痛点。
事实证明，我在决定何时使用React Native或Ionic时，很多决策主要归结为非技术驱动因素。如果我必须把五年来在这两个框架之间来回工作的经验归纳起来，并提供一个 "小抄"，它看起来会是这样的。
- 你是否在构建一个严重依赖原生功能设计的体验 比如Snapchat? 我会选择React Native。
- 你是否被赋予了一个复杂的设计，应该跨平台匹配？Ionic。
- 你是否想试水某个特定的市场或业务能力，看看用户是否会接受？我会建议Ionic，因为它的预制设计可以让自己更快地进入市场，但这两个框架在这种情况下都很出色。
不过最终还是要把这两个框架都试一试。不要以为一个框架比另一个好。通过几个POC项目，你很快就能确定哪个框架最适合你的项目、你的开发人员和你的业务。
通过www.DeepL.com/Translator（免费版）翻译
