所以本次也是带着讨论的角度来展开，没什么深入技术分析，因为也没什么源码可以看到，主要从文档出发，从看官方介绍可以看到：
"在App端，uni-appx在iOS编译为swift、在Android编译为kotlin。没有使用js引擎、webview，完全达到了原生应用的功能、性能。"
那就是说这是一个将uts代码编译为原生代码去运行的框架，那在没有js引擎的情况下，是不是意味着基本大部分npm上的js库都不支持了？毕竟没有js引擎了，我也比较好奇uni-app用户应该是小程序开发居多，那么npm不兼容对选择的影响会有多大？
“uts替代的是js，而uvue替代的就是html和css。或者如果你了解flutter的话，也可以理解为uts对标dart，而uvue对标flutter。”
在使用uts这个基础上，uts是否就和Dart一样，需要重新构建一套开发者语言生态？虽然uts和js类似所以成本会比较低，但是也需要「好心人」or「企业」本身去做这个事情，我想这个问题会是uni-appx是否持续存活的关键，毕竟大部分开发者要的是「开箱即用」，「用爱发电」这种事情只有极少数愿意去做。
"uvue支持的vue语法，是按vue3实现的，uvue支持的css语法，是web的子集，类似于nvue的css，仅支持flex布局"
所以整个生态还是需要Vue和JS开发者们来参与，不兼容Vue2这个貌似问题不大？
如果编译适配真的做的不错，那么性能说不定对比uni-app会好很多，因为weex还是需要jscore和运行时的OEM转换，但是如果直接编译为原生UI，那就几乎可以说和原生UI一样的运行逻辑，我这样理解应该没错吧？
因为我没看到编译转换部分的代码，所以也只能猜测就是uts转为kotlin下的AndroidView去进行布局这样的理解，也就是运行时其实就是一个原生App。
从官方给出的迁移指南上看，基本上难度还是在于plugin和css样式上，也就是如果以前你不用uvue，单纯用uni-app开发小程序和直接打包出App的话，我理解还不如重写，例如uni-appx里就不支持uvue页面和vue页面混写，你必须都是uvue。
另外，由于政策等限制，uni-appx官方在打包后不提供热更新支持，这个也可以理解，可执行二进制文件的热更新不符合规范，官方如果内置就会导致上架问题，你可以自己二次开发，但是官方绝不能内置。
当然，因为uni-appx的特殊性，所以目前绝对性的开发只能用HBuilderX，如果你能做到用txt写代码那确实可以不用HBuilderX，不过HBuilderX的体验一直都是难以言喻就是了。
总的来看，它就是转译为原生，所以它即不是weex路线，也不是flutter路线，因为它既依赖于平台，又不依赖于中间运行时。
如果说uni-app的定位像是以小程序为主，App为辅助，那么uni-appx更像是App为主，小程序为辅。
所遇uni-app这次尝试很大胆，因为2023年了App市场其实还有多少余地？可以遇见，后续uni-appx会存在两端对齐的UI问题，weex/rn走过的路，样式对齐和OS不同版本API兼容问题也会需要处理，例如：
在Android上调好的样式，在iOS上出现适配异常，因为不像是Flutter直接通过GPU绘制出一致UI，平台对齐一直是一个手工活，以前通过webview可以简单屏蔽，但是自己做就需要不同平台不同OS版本都去ifelse，是个大苦力活。当然，反过来看，这样也很好保留了本身的控件特性。
总结来说：如果ReactNative和Weex是运行时将jsview转为nativeview去渲染，那么uts+uvue就是编译时把uts转化为kotlinview和swiftview去打包。
在我理解上，一家商业公司做这个，我觉得除非完全开源（不是半开源），然后基于社区大量投入去做运营，不然单靠内部开发去推进这件事情进度会很慢，因为这个项目的实现逻辑注定了它需要大量的适配工作，类似Flutter，而Flutter大量的bugfix和适配都来自社区的pr，很多问题都是依靠社区贡献去修复。
当然，就像官方说的，如果你觉得uni-app已经性能够用了，那其实完全不必考虑uni-appx，而就像大家说的，我都用uni-app了，还考虑什么性能？
最后，其实今天更多是讨论的味道，其实uni-app的用户还是不少，我很好奇，有多少uni-app的用户愿意去使用uni-appx，这只螃蟹未来是否可以在跨平台领域横行？你愿意学习uts和uvue吗？