React NativeScript 创建者 Jamie Birch 的访谈
鉴于 React Native 已经存在相当长的时间（几乎和 NativeScript 一样长！），NativeScript 社区想要承担为 NativeScript 创建 React 集成的任务可能看起来很奇怪。
但是，React Native 和 NativeScript 的架构（以及开发者体验）之间存在一些显著的差异，NativeScript 带来了很多关键优势。所有这些都促使 Jamie Birch 启动了 React NativeScript 项目。
为什么是 React NativeScript？ Jamie 很好地概述了 React Native 和 React NativeScript 之间的一些关键差异
为了从 Jamie 那里获得更多关于是什么激励他将精力集中在 React NativeScript 上的背景信息，我们向他提出了一系列关于该计划过去、现在和未来的问题
你的技术背景是什么？
我四年前通过参加计算机科学的硕士级转换课程开始编程。现在我是一名软件工程师，在 Strategy & Technology 工作，主要参与制作混合广播宽带电视 (HbbTV) 应用程序。在空闲时间，我涉足原生和跨平台（以前是 React Native；现在是 NativeScript）应用程序。
最初是什么吸引你使用 React 框架？
我喜欢 React 如何保持事物相对简单：严格的单向数据绑定；直接使用 JS 表达式而不是模板语法或指令；以及它如何认为自己只是一个 UI 库，而不是一个有主见的应用程序框架。事实证明，它似乎是业界最受欢迎的 UI 库，这最终促成了我的决定。
是什么激励你用 NativeScript 和 React 启动一个新的社区计划？
我已经尝试过 React Native 一段时间，并且很喜欢它将原生应用程序习语转换为对 Web 开发人员来说更熟悉的概念（即 CSS、Flexbox 和 React）的方法。但是，我也逐渐意识到，在 React Native 中访问原生 API 远非符合人体工程学。设置原生模块是一个巨大的时间消耗，并且同步应用程序的原生和 JS 上下文的状态一直很痛苦。这两个问题都是由于异步、基于 JSON 的 JS-原生桥接造成的。
不知何故，我偶然发现了 NativeScript，惊讶地了解到一个基于 TypeScript 的跨平台框架。我立即被它的新颖架构所吸引：每个原生 API 都可以同步访问，并且所有数据类型都可以无缝地来回传递到 JS 和原生上下文之间（不再需要 JSON 序列化）。简而言之，没有桥接——原生代码可以直接在 JS 中编写。
所以我开始用 NativeScript Core 制作了几个应用程序，但我最终发现很难掌握 NativeScript Core 的 XML 语法及其数据绑定，并且错过了以声明式方式编码的能力。基本上，虽然我喜欢 NativeScript，但我希望重用我对 React 的现有知识，而不是学习另一个新的框架。
我得出的结论是，答案是将 React 引入 NativeScript！我于 2019 年 3 月 20 日开始这项任务，完全利用零星的闲暇时间进行构建，并且没有任何制作自定义 React 渲染器（本身就是一种文档不足的艺术）的经验。
为什么是 NativeScript？为什么不是 Cordova 或其他基于 WebView 的选项？
虽然许多跨平台框架都有某种解决方案来访问原生 API，但 NativeScript 在提供对 100% 平台 API 的同步 JS 绑定（包括所有数据类型的编组）方面是独一无二的，并附带 TypeScript 声明。很难描述在 TypeScript 文件中间调用原生代码的同步体验是多么神奇。
至于基于 WebView 的框架，我自己没有尝试过任何一个，但常见的论点是它们在资源消耗方面不成比例地高，并且提供较差的用户体验（至少在某些方面是这样）。
React NativeScript 有什么特别之处？React NativeScript 与 React Native 有什么区别？
简而言之，我喜欢将其视为React Native 的无桥替代品。你获得了 React Native 的大部分开发者体验（例如 TypeScript、Flexbox 和 CSS），但可以同步访问 100% 的平台 API。哦，如果你来自 Web 开发背景，React NativeScript 使用 Webpack 作为其捆绑器可能是一个受欢迎的变化，而不是 Metro。
反向推销：React Native 当然仍然在这个世界中占有一席之地。它拥有广泛的平台覆盖范围，一个庞大的现有库生态系统，并且在行业中得到了广泛的应用，这一点毋庸置疑。
但是，如果你希望紧密且频繁地使用原生代码——尤其是如果你预见到在 JS 和原生之间进行大量上下文切换——那么我真的很推荐你尝试 React NativeScript。它是专门为解决 React Native 的原生访问痛点而创建的。
你从 React Native 团队（或社区）那里收到过任何反馈吗？
令我惊讶的是，我完全没有从 React Native 核心团队那里听到任何消息。社区中有一些好奇的兴趣，但还没有真正形成势头。React NodeGUI（用于桌面应用程序开发的 React 渲染器）是一个类似的想法，并且最近开始流行起来，所以我认为，只要稍微多一些曝光度，React NativeScript 就拥有所有元素，可以迅速发展成更大的事物。
你对 React NativeScript 的近期和长期计划是什么？
我的下一个紧迫任务是发布一个文档网站，因为这是采用它最后一个真正的障碍。我还希望就 React NativeScript 做一些会议演讲，让它获得更多知名度，并吸引合作者。
从长远来看，我希望 React NativeScript 与 React Native 具有某种形式的兼容性。也就是说，能够使用 React Native 插件（Stanisław Chmiela 的概念验证为这一点开创了先例），并最终能够使用完整的代码库（React Native Web 是从一个 React 渲染器转换为另一个渲染器——从原生到 DOM——的成功示例，我开始了一个概念验证来调查从原生到 NativeScript 的转换）。互操作性将允许 React NativeScript 借鉴非常大的 React Native 社区的努力。最终目标是将两者结合起来：让 React NativeScript 能够访问整个 React Native 生态系统，同时又是无桥的。
在某个时候，我希望有机会实际使用它来重建我的应用程序，这个应用程序在移植到 React Native 时遇到了很多摩擦，并让我开始了整个项目：LinguaBrowse。这是一个用于外语互联网的 Web 浏览器，如果你好奇的话。即使你不感兴趣！
社区中的其他人可以做些什么来帮助？
现在我已经 构建了基础，我希望社区能够扩展核心代码库和整个生态系统。例如，如果 NativeScript UI 插件作者可以添加对 React 的支持，那就太好了，所以我希望尽快稳定 API 并对其进行文档化。文档的翻译将始终受到欢迎。并且有一个为导航框架构建的开放利基市场。
但最重要的是，看到人们用 React NativeScript 构建应用程序会很棒。通过构建应用程序，我们可以确定库中缺少哪些内容，并阐明最佳实践。
这是我制作的第一个如此规模的开源项目，我逐渐认识到一个令人谦卑的现实，即我无法身处所有地方，同时做所有事情。我欢迎所有帮助改进 React NativeScript 的行动，并希望在协调社区努力方面尽我所能。
像往常一样，如果你在使用 React NativeScript 时遇到任何困难，请随时 提交问题。如果你更需要一些对话，我们很乐意在 NativeScript 社区 Slack 的 #react 频道中提供帮助。