react native 在 2024 年还能打吗？感觉跨平台一致性不如 h5 和 flutter

跨平台就是在吃屎，框架多吃点你就少吃点，框架少吃点你就多吃点，框架说有些屎实在咽不下，你就要含着泪咽下去，要是你也咽不下去，就要混在饭里端给用户了

个人觉得跨端框架大同小异，坑都不少，选择自己熟悉的就好。所谓的高性能都是噱头，再高也比不过 native 。不少大厂在跟了一波 flutter 的热度后又用回 react native 了

之前我们尝试了一波迁移 rn ，后来放弃了，改成 capacitor 了，还是 h5 适合我们

rn 的样式问题老生常谈了，跟原生 css 比，除了像 css 也没啥区别了

还有新架构年底才正式适配，那么一大坨 c++代码生怕啥时候编译就出问题

赞同一楼，完全一致性的跨平台方案不存在，假如纯原生开发工作量是 1+1+1 等于 3 ，跨平台顶多减少到 2 ，部分业务能少到 1.5 就不错了

不能打了，不如 h5 和 flutter 了。。。flutter 肯定是不能完美做到的。需要等待一个时机。。。

RN 本来就不是为了一致啊，很多用的平台 UI 。。。。

无脑 flutter

不如 h5 和 flutter

无脑 flutter

我选择 React Native ，会写 React 上手贼快
很多钩子库还通用

这个问题看了 n 个人发 能获得 n 个不同的意见，哈哈哈 真是个困难的抉择

来个始皇帝统一下基础规范行不行。
各个平台都搞一套百分之八十都差不多的东西，完全就是浪费。

这几个方案针对的都不是一个东西，RN 是强调开发速度，让有 react 经验的程序员快速上手 App 开发，减少原生开发的前置学习时间和成本。同时提供一个还不错的跨端性能。

要根据你项目选方案啊，如果是公司体量大且是购物和社交这种注重用户体验的就原生 > flutter > rn ，否则就选生态好的比如 rn 、h5 套壳，迭代成本和维护成本也得考虑进去。

我们现在直接只用 Web(React, 当然也可以 vue 等)，然后用 capacitorjs 来打包原生。这个可以实现 iOS/Android 的 Native bridge ，可以在 Javascript 里面调用原生代码。
其实我们主要就是用个原生 push ，capacitorjs 已经封装好了，能一键接入 FCM 和 iOS 的 APNs

现在阶段，小程序的 uniapp ，app 用 flutter 。其他成本太高

@minami 豪赤 , 爱吃

rn 最近版本变化挺大

没有完美的跨平台方案。

反正我挺赞同 @murmur 之前帖子的观点，flutter 写 ui 语法太初生了。

前端的你想像一下像 vue 完全不用 template 只用 h 函数一层层嵌套的 ui ，上千行的 ui 代码你看得来吗，尤其是有些不爱拆组件化的程序员，改这种公司的代码真的得吐血。

然后状态管理库也是 react 玩剩的类 redux ，rn 的其实你用 tailwindcss 的话极少出现 ui 不一致的问题。最多也就安卓和 ios 的 rn api 不一致问题，比如 rn 的 alert ios 能用安卓不行。

rn 最大的问题是国内生态不行，很多国内 flutter 有的 sdk rn 没有，需要 rn 开发者自己写，这就要求 rn 开发者一个人至少会 swift ，kotlin ，js 三门语言并熟练，离谱点甚至 oc 和 java 都要会，然后薪资甚至不如只会熟练一门语言的 java 和 golang 后端

@yb2313 背靠前端你就偷着乐吧，写跨平台 c++的天天粪池蝶泳

我悄悄的提一嘴 uniapp 不会挨骂吧

@yrj uniapp 是做那种小项目和办公 app 的好东西

uniapp 其实最大问题是云打包，各种跟云绑定，现在 gov 大企业要求本地全部源码，直接一票否决了

我也在找
用过 RN ，说实话没啥大问题，最低选择
用过 Flutter, 不写界面的时候很爽，要写的时候噩梦，而且不是 js ，现在也好像被抛弃了，建议放弃

如果只是小程序的话，那选择太多了，taro ，raxjs 都可以，但是如果要想有高性能，还是只能原生写，如果是简单项目建议原生，多人协作用 taro ，至少开发速度不会变慢，性能问题找其他方式解决
uniapp 这种就是给待退休或者不专业程序员用的，不建议普通人用，没任何好处，坏处特别多，没办法还是得照顾国内很大一批跟不上时代的程序员

capacitorjs 的话，我先去踩踩坑