RN缺少什么才能成为构建应用程序的默认框架

所以，我试着开发可以在所有平台(iOS、Android、Windows、Mac)上运行的应用程序，由于微软(Facebook现在也加入了这股潮流)，Reaction-Native最近宣布增加了对MacOS的支持，这让我感到鼓舞(Facebook现在也加入了这股潮流)，所以经过几个月的开发，我不得不放弃，摩擦太多了，我是一个人团队在我的FreeTime上开发这个程序，让我解释一下我的一些痛点。

本机反应的一大优点是它是由每个平台的本机组件和API支撑的，但是…。这也是一个诅咒，我已经接受了Reaction-Native-MacOS还没有准备好进入黄金时间，我可以绕过许多问题，尽管是妥协，但当我试图绘制矢量图形时，我已经到了崩溃的地步。

目前，如果您想要在REACTION-NATIVE上绘制矢量图形，默认选择是REACTION-NATIVE-SVG，奇怪的是MacOS(或Windows)不支持它，可能有一天会支持，但您将受制于命运和慈善的力量，直到有人花时间将其移植到每个平台，这可能需要几个月或几年，这只是最基本的东西，有数百个库需要移植到每个平台。

对于我来说，这是一个不断重复的故事(不仅是在MacOS上)，现在我已经和RN合作了几年，每次我到了库被左右抛弃的地步，新功能需要对平台和构建系统有深刻的了解，当你试图做一个足够大的应用程序时，会出现重大的性能问题，等等。

反应导航？您只能使用2.x版，该版本没有本机依赖项，已弃用多年，其他库如相机、位置等…。你可以把它们忘掉几个月/几年。

目前正在开发的Windows和MacOS端口的理念是，所有支持的平台都应该具有1对1的功能奇偶校验，这也包括行为奇偶校验。

从表面上看，这听起来很合理，但事实并非如此，因为移动和桌面的行为不同，使用键盘和鼠标与应用程序交互的方式与移动不同：在桌面上，键盘快捷键支持是必须的，能够检测组合键是必须的，RN不支持任何这些，甚至数字键盘的一些默认行为也不能很好地转换到物理机上，另一件事是应用程序生命周期(焦点/模糊)与移动应用程序的生命周期绑定到不同的规则。

充其量，你最终会得到一个在桌面上使用起来很奇怪的应用程序(UI不受欢迎，这里只谈UX)

你想自己修补这个吗？我只能祝你好运，你知道obj-c吗？核心图形？Windows API？Android Java？格雷德？您是否了解Reaction-Native的内部结构以及如何创建您自己的组件？使用桥创建代码？这也是很慢的…。，有Turbo模块开始，您可以将c++添加到您需要学习的内容堆中。

那韦伯呢？然后，您必须在Rn之上堆叠另一个框架，该框架具有自己的怪癖和错误…。我真的认为这里的哲学是失败的，在原生反应上有很大的希望，但在目前的道路上，我就是看不到任何不是Facebook规模的公司来处理这些问题的可持续性。

目前我正在研究纯网络技术和电子，电子因为安装和内存消耗的大小而受到很多抨击，但Chrome本身就是一个操作系统，所以很多这些小细节都被一个高薪团队抽象出来，并用低级实现编写了解决方案，这真的很令人惊讶，Web API已经进步了这么多，现在有了WebAssembly，可能性比以往任何时候都大，不是说它是完美的，但它肯定比OSS社区和一大批公司(都有不同的动机)来修补它要好得多。

至于我，我将开始探索在纯web上开发应用程序的可能性，并创建大量使用嵌入式web视图的浅层本地应用程序，我记得我在basecamp看过几个人的视频，他们有一个很小的本地团队，他们只编写小型容器应用程序，但大部分工作都在Web上，可以在浅层容器中重复使用，这似乎是最合理的事情(即使你必须学习每个操作系统的基础知识才能创建容器应用程序，但无论如何你都要用RN来做这件事)。