微软更新 React Native for Windows，引发开发者疑问：“为何不用 MAUI？”
微软已发布 React Native for Windows 0.81 版本，新增了对移动端同款 Hermes 调试器的支持。但其版本进度仍落后于已升至 0.83 版的 Android 与 iOS 版本。
尽管版本有所滞后，微软已在 Outlook、Teams 等移动应用，以及 Office 桌面版的部分功能和 Power Apps 低代码平台中广泛采用了 React Native 框架。这与 MAUI（.NET Multi-platform App UI，微软官方的 .NET 跨平台 UI 框架）形成了对比。MAUI 是微软向开发者主推的框架，但其在微软内部的实际应用却相当有限。
Hermes 是 React Native 的默认 JavaScript 引擎，通过预编译优化实现快速启动。此次更新让开发者可以借助 React Native DevTools（基于 Chrome DevTools）调试 JavaScript 代码，实现断点设置、变量查看、性能分析、内存快照及组件检查等功能。据开发团队介绍，“Windows 开发者现在可以获得与 Android 和 iOS 相同的调试体验。”
然而，严格来说情况略有出入——DevTools 中的网络与性能选项卡目前仍不可用，预计将在 Windows 版本达到 0.83 时提供。
React Native Gallery 应用已上架 Windows 应用商店，其源码可在 GitHub 上获取，展示了丰富的组件与资源示例。
此次新版本还带来了组件层面的改进，包括更优的文本处理能力和可访问性增强。
React Native 最初由 Meta（原 Facebook）开发，其目标是让开发者能够使用 JavaScript 和 React 编写跨平台的原生应用界面。它并非使用 Web 视图，而是直接渲染原生控件。开发者可以使用同一套 React 框架代码逻辑，在 Web 应用和移动应用间共享，但 UI 部分会分别渲染为 Web DOM 和原生平台控件。因此，开发者无需依赖嵌入式浏览器，就能在保持原生界面视觉效果与操作质感的前提下，实现代码复用。
该框架被 Meta 用于 Facebook 和 Instagram 等移动应用，也被亚马逊、Shopify 等其他公司采用。
2018 年，React Native 团队启动了新架构的开发工作，其中包括一个名为 Fabric 的渲染系统，其性能优于旧有的、用于 JavaScript 与原生组件间通信的“桥梁”（Bridge）机制。Windows 平台的实现也已迁移到新架构，而此次发布的 0.81 版本将是最后一个同时兼容旧架构的版本。
React Native 的一个重要特性是允许开发者集成平台特有的高性能代码或现有库，即支持原生代码模块。在旧架构中，开发者可以在 Windows 应用中使用 C++ 或 C# 模块。然而，新架构不再支持 C#，仅支持 C++。根据官方文档的解释，“绝大多数 React Native for Windows 应用和库，更不用说框架本身，都是用 C++ 编写的，因此团队优先支持 C++。”
团队计划在未来支持 C#，但表示目前“已有的支持还远不够稳健，不足以支撑整个 React Native 生态系统。”
这只是使用 React Native for Windows 进行开发的注意事项之一。另一个问题是，与广泛使用的 iOS 和 Android 版本相比，其第三方支持较为有限。React Native 的包注册表显示，有超过 2000 个包适用于移动平台，但仅有 67 个适用于 Windows。
尽管存在这些注意事项，并且在版本更新上有所滞后，但 React Native for Windows 的未来依然稳固，这主要得益于微软 Office 团队的内部深度使用。该公司去年曾表示，React Native“对于 Office 的现代化改造至关重要”，并且通过“内容岛”机制，React Native 组件可无缝嵌入主应用界面，确保跨平台体验的一致性。
JavaScript/TypeScript 的流行意味着，对于同时需要构建桌面与移动应用的团队而言，考虑到微软自身在 Office 中的深度投入，React Native for Windows 不仅是一个可行的技术选择，更是一个值得关注的长期方案。
但一个关键疑问随之浮现：既然两个框架都支持高级语言与原生渲染，为何微软要同时维护两套体系？有开发者在评论区抛出疑问：“为何 Office 团队不选用 MAUI？”至今仍未得到官方回应。
究其原因，除了技术层面的考量，或许也反映了微软内部（例如开发者部门与 Windows、Office 团队之间）长期存在的策略或技术路线差异。