2019 年的年底还是会见到脱离场景，无脑把 RN 和 flutter 扫入垃圾堆的

[MorningStar0]

早上起来在 B 站看到一个视频，下面有个人回复

我想说，用 js 写出来的 web app，包括 react native 这种混合开发 app，都是**！ js 想染指移动端饿死 java 和 oc 想太多了...谷歌自家推出的 flutter 想跨界移动端能否成功都遥遥无期，js 靠边站站

我寻思，这 APP 交互性的好坏难道不是由开发者的水平和产品设计决定的么。而且如果我只是一个活动页，或者简单的论坛（早期的牛客网）真的有必要完全用原生么（从性能、开发周期和后期迭代权衡来看）？

在后面的对线中，他提出要比比 rn 和原生的性能，我就怼了句你真的理解 rn 要解决的问题么？，然后收到了如下回复。

页面出现了，网络请求成功了，对你来说就是一个 app。。。。笑死

emm...第一次见到，原生开发者对 rn 这样的跨平台 UI 框架存在这么大恶意的

[DoUSeeMe]

@lagoon 今天还更新了新版本 flutter，谷歌对亲儿子还是会好点的

[hyy1995]

原生开发者对跨平台框架有恶意是正常的，毕竟涉及到抢饭碗问题。现在很多中小型公司都不会招 Android 和 IOS 开发的，节约成本，有前端人员就够了。



“react native 这种混合开发 app”——话说 rn 不是 native app 么，跟混合 app 是两码事啊，混合 app 是套的 webview，性能肯定不行，但是 rn 这种 native app 编译出来的就是原生应用啊，虽然那些个插件对比原生确实还是存在差距，但差不太多。。。

[hyy1995]

另外，跨平台已是趋势，无法阻挡，可能再过几年，就能真正替代掉原生开发。可以想想几年前的前端框架，跟现在的差距对比。。。

[oahebky]

原生+web 是必然趋势。
原生用于接广告时满足广告投放客户的“精准投放”需求。
web 用于快速迭代、试验新产品、新活动。

从大型公司来看，app 内部换成:
+-------++-----+ +--------+
| java | | 框 | | Web |
| UI | | 架 | | app |
+------+ +-----+ +--------+
也是一种比较聪明的选择。
app 框架层可以在 android 和 ios 适配。
未来有新系统加入开发起来省了一半以上功夫（所有 feature 不用从头一个一个 merge 过去，只要适配好框架层就 OK 了，用黑盒、白盒测试框架也可以直接保留）

[BigDogWang]

短期内应该是不会学这些东西的，对 UI 开发已经了无兴趣了。

[BigDogWang]

不过还是不太看好 flutter。原生+网页混合开发不错

[damngood]

@hyy1995 我大部分时间是 iOS 原生开发, 也用 RN 开发过两个 App, 无论是产品体验还是开发体验, 和原生开发还是有不小差距的.

产品体验有差距当然也有可能是我前端水平不够的因素在里面, 但是开发体验还真是没得比.

几年后的情况还比较难说, 像现在的 SwiftUI 或者是 Jetpack Composer 这种技术如果成熟了, 而且有其他平台的 port, 那开发者估计还真不太愿意用现有的这几种跨平台的方案.

据我所知, 至少 SwiftUI 已经有人着手在做其他平台的移植. ( 我很期待这个 )

[murmur]

@hyy1995 但是 apple 这次的目的很明显不是解决性能问题，而是为了解决马甲包和非法应用的问题，那么具有动态性能的框架和 app 都会被下架，h5 自然要杀，react native 也跑不掉
以前针对博彩、成人内容这些也有严打，但是很明显力度不够，你有检测方法别人就有开关机制，所以会不会直接封框架，就检测有没有用 rn、cordova 这些

[qinfensky]

@weixiangzhe 对我造成了困扰，我还是换个稳固方案好了

[behanga]

rn 最主要解决的问题：
1.人力资源问题，一个功能两端实现，两份人力，两份工资。
2.热更新，不依赖 app 的发版。

以后长期都会是原生开发，rn，hybrid 共生的环境。这些都是因为业务形态做的取舍，没有谁将会取代谁的情况。

[Balthild]

@janus77 首先 RN 和 Flutter 根本就不是什么“浏览器页面开发”，其次它们都可以调用平台原本的语言来实现系统相关的非 UI 特性

[secondwtq]

@murmur 我的理解，Apple 此举的主要目的，通俗地说就是禁止热更新（应用送审后行为不能改变，或者说与外界通信内容仅限于数据，不能传输程序）。
还有一种可能是遏止非原生框架（包括“H5“）的大量使用对体验的劣化，不过我个人偏向于前者。
所以理想情况应该是封有热更新行为的应用，但如 #48 所说这并不现实。之所以单独拎出”H5”，以及专门扯了一堆 WebKit JavaScriptCore 之类的，是因为使用“H5”和热更新这两者之间有一种奇妙的强关联，基本一抓一个准很少有错的，事实上就官方声明来看已经对“H5“采取了一刀切的手段。

但是我不认为所有类似的跨平台框架都在 Apple 的目标之内，因为”跨平台”和”热更新”根本就是两个正交的需求（虽然可以用同样的技术手段解决）。跨平台框架可以不做热更新。并且理论上，跨平台框架也可以做到把所有东西塞到一个 binary 里面（只是目前可能还很少这么做），至少可以满足技术上的要求（不运行 binary 以外的代码）。
“热更新”（或者广义上的执行非自身 binary 中的代码）也不是禁了已有的框架等具体的技术就能禁的，因为“数据”和“程序”其实是无法区分的。甚至一个程序有没有“热更新”行为也很难界定。

最极端的情况是有实力也有需求的大厂自己造私有的跨平台 /热更新的框架。想到这最搞笑的是，如果真有人用这种方法绕过热更新限制，那就没法做 JIT 的现状和某些华而不实的大厂的真实水平来看，可能最后体验还不如 H5

[loginbygoogle]

区区 web 前端也想学 flutter，可能不配。

[noobcoder1]

@loginbygoogle 这年头 已经没什么门槛了 只要认真学 都能很快能上手