我们时代的问题

“ 我想启动一个网站及其移动伴侣应用程序。 该应用程序将在iOS和Android上均可用。 我听说React Native非常适合我。 真的吗？ ”🙍

有两种类型的用户。 那些使用计算机访问自己喜欢的网站的人，以及越来越多的喜欢使用这些网站的移动应用程序对应对象的人。

Facebook报告称，其中74％的用户浏览了全球最大的移动社交网络 在2017年。

考虑到这一点，作为产品的创建者/经理，您确实希望将其交付给最大的受众的机会很高：对于这两种类型的用户。

但是更糟糕的是 ，移动端本身可以分为两个更具竞争性的子类型。 即苹果和安卓 。

问题：用于实现网站 ， iOS应用程序的编程语言 或Android应用程序 本质上彼此不同。

那么，这具体意味着什么？ 好吧，如果您在一个平台上实施产品，该代码将不会“移植”到其他两个平台中的任何一个：大多数代码都将不得不重新编写。

换句话说，这意味着您的产品成本（几乎）必须乘以您希望支持的平台数量…

在大多数西方国家中，中型移动应用的平均价格在20万至50万美元之间，而网站的平均价格在5万至25万美元之间，您可能会怀疑：

“好吧，但是，我是否可以不统一那些语言，并且对所有平台仅实施一次我的应用程序？ ”💁

反应 是Facebook开发的开源框架。 它于2013年推出，允许开发人员基于可重用的可视组件（例如，包含聊天中文本内容和时间戳的自定义蓝色Message气泡），使用JavaScript创建高级的Web用户界面。 它可以处理随时间变化的数据，而无需重新加载页面。

React Native也由Facebook开发。 两年后宣布，它扩展并把其哥哥React的力量带入了移动世界。 您将能够使用JavaScript编写您的移动应用程序。 您操作的元素将iOS和Android本机可关联元素包装到一个单独的React Native对象中，从而暴露出一个统一的API（例如，React Native scrollView元素桥接到iOS的UIScrollView和Android的ListView中）。

因为React Native建立在React之上，并且因为它们都依赖于相同的语言，所以这使他们有可能在诸如业务逻辑和后端集成等各种领域中进行大量协作。 这意味着，除了上述React Native提供的iOS和Android之间的统一之外，现在还可以在Web和Mobile之间建立桥梁。

框架的标题“ 学习一次，随处写 ”是一个 在Java的“一次编写，随处运行”上玩，现在变得更有意义：一旦您了解JavaScript和React工具集，就可以在任何类型的平台上实现所需的任何东西！

“ 好的，React Native为我提供了一种统一的语言，但是您仍然告诉我，我需要编写3种不同的代码库吗？ 有什么意义？ ” ‍🤷‍

好吧，React Native 实际上使在iOS ， Android和Web之间共享许多代码成为可能。 即使很大一部分仍必须是特定于平台的，也可能不需要雇用任何移动本地开发人员！

”“ 哈，这很有意义！ 但是等等，在这种情况下我应该雇用谁？ ”🙋

正如本机移动开发人员所看到的

React Native为Web和iOS和Android开发人员带来了许多现代工具和功能。 显然，这包括在两个平台上均以最大程度的代码重用和成本节省来部署应用程序，作为框架核心部分的响应式范例以及令人兴奋的内容，例如热重载（即时重载视图，而无需等待1分钟即可重新编译整个项目）。

但是，本机开发人员向React Native过渡存在许多不可忽略的挑战。 经过大量的努力学习掌握他们的本机工具/语言的集合，现在他们觉得自己有很好的专业知识，您将要他们消灭大部分工具，并再次努力从头开始学习新的复合材料以及不使用官方工具集（例如Xcode或Android Studio ）的“ hacky”方法，官方指南也不建议使用。

您的开发人员将需要放弃他们钟爱的界面编辑器，这些编辑器将提供功能强大的约束系统，从而使Flexbox （React Native完全以编程方式进行UI布局的方式）受益。

相对较新且未广泛使用，当您遇到一个奇怪的错误时，Internet不会在React Native上提供太多帮助-在您使用的最初几周中，可能会有很多帮助。 除了无法从其本机IDE上惯用的强大调试功能中受益之外，这还使故障排除更加麻烦。

正如Web开发人员所见

React Native通过使用JavaScript作为主要编程语言编写本机应用程序，使Web开发人员可以访问iOS和Android上的本机开发。

由于它还依赖于类似CSS的样式语言和类似XML的UI元素声明，因此 开发人员将能够立即采用这个概念。 这将使他们几乎不需要学习新语言即可实现本机移动应用程序。

也不要低估Web开发人员首次在本地移动应用程序上工作的有趣和令人兴奋的方面。 看到您手中的作品可以编译，在触摸屏上玩耍并愉快地重用Apple和Android本机UI元素-Web开发人员不习惯在浏览器上使用。 当您来自本地移动开发背景时，您不会获得令人兴奋的方面。

过渡复杂度不均

从Web过渡到React Native确实没有任何缺点。 它更像是扩展自己当前的Web开发知识以完成新事物。

从本地开发过渡到React Native比从Web过渡需要更多的学习曲线（和更少的乐趣），以完成几乎相同的事情。 尽管如此，仍然有许多人成功采用它的例子，甚至声称他们将永远不会再进行本机开发（请阅读React上一篇出色的iOS开发者文章）。

反应本机 在移动开发人员和Web开发人员之间架起一座鸿沟。 它使这些团队可以更顺畅地合作，尽管更容易过渡到Web开发人员，但仍然为双方带来了好处。

因此，如果您的团队是本机开发人员和Web开发人员的混合体，那么您似乎仍然处于理想的配置中，并且随着时间的推移，您甚至可以减少对前者的需求。 如果您的团队仅由Web开发人员组成，则可能根本不需要雇用任何本地开发人员。 对于仅由本机开发人员组成的团队来说，这似乎更艰难-但这并非不可能。

“ 哇，这对我的Web开发人员来说真是太神奇了。 那么PhoneGap和Titanium呢？ 我听到了很多关于那些狐狸的消息，它们更好吗？ ”🙅

与PhoneGap和所有其他基于Cordova的解决方案（例如Ionic）不同，React Native不会生成基于Web View的应用程序 。 JavaScript代码已桥接到本地语言，最终应用程序是完全本地的。 React Native具有更好的性能和更流畅的动画。

PhoneGap的展示柜展示了知名应用程序中的明显缺点。 相反，从混合/本地迁移到React Native的应用程序的公开列表很长（Facebook，Airbnb，Instagram等）。 在Fueled，我们已经看到许多客户将其混合应用程序转换为本地应用程序。 如今，要找到一种从React Native / native转变为混合动力的高端应用程序无疑将是一个很大的挑战。

与Titanium不同，React Native将反应式引入了构建基于组件的用户界面的范例。 简单地将应用程序UI表示为当前应用程序状态的函数，大大简化了有时可能成为复杂状态机的开发，并提高了代码的可读性。

React Native还提供了一种依靠Chrome或Safari的控制台/调试器的高级调试方法。 通过允许您很好地检查UI元素，更好地帮助您解决布局问题和查看相关问题。

尽管如此，React Native和Titanium是非常相似的框架。 两者均使用JavaScript编写并生成本机应用程序，且速度都很快，并且都能够在iOS和Android上进行部署。

与Flutter不同，React Native应用程序是用JavaScript开发的。 Flutter依赖于一种名为Dart的语言，该语言已桥接到相应的本地语言（如React Native）中。 Dart是一种相当冗长的OOP语言，需要您的开发人员花些时间来熟悉。

推荐用于Flutter开发的IDE是Android Studio，它的最大优点之一就是可以利用其广泛的工具集。

但是Flutter还以风格方面的竞争力较弱（没有分离到样式，模板和控制器）而闻名，布局视图和实现动画更加困难，并且无法控制应用程序的生命周期。

Flutter比React Native年龄小得多，在追赶上还有很长的路要走。 尽管有希望并提供类似功能，但开发人员社区倾向于同意它目前似乎没有竞争力。

在Fueled，每个iOS和Android开发人员都有一个扎实的团队，在采用React Native还是坚持使用Native应用程序之间的选择一直是激烈而持久的讨论。

我们坚信，除了以上详述的所有证据外，还应根据每个项目彻底讨论此选择。 有许多重要的影响因素可以考虑影响这一决定。

最强烈的要求之一可能是客户希望使用整合技术，在这种情况下，如果听起来不合适，您可能想退缩，或者发现自己受到该约束的束缚。

再举一个例子，很多预算有限的客户宁愿只专注于一个平台（通常是iOS），如果产品起飞，以后再在另一个平台上进行迭代。 使用React Native，尽管使其也可以移植到Android上，但开发的第一阶段将花费更多的时间来获得相同质量的可交付成果，并且对于分配的预算而言可能过于昂贵。

对于我们在Fueled开发的大多数项目，我们都倾向于在较短的迭代周期内实现更快的开发，而我们的技术团队也已经在本地开发方面拥有强大的专业知识。 在这些情况下，React Native将在项目的早期阶段显着影响我们的开发速度。 但是，对于具有较大代码库的长期项目，可能（并且希望）在多个平台（iOS，Android和Web）之间共享代码，尤其是在团队已经支持深入的Web专业知识的情况下，这样做更有意义。

在 这里 阅读原始故事 。