2019 年的年底还是会见到脱离场景，无脑把 RN 和 flutter 扫入垃圾堆的
MorningStar0 · 2019-12-12 13:32:44 +08:00 · 6662 次点击这是一个创建于 1845 天前的主题，其中的信息可能已经有所发展或是发生改变。
早上起来在 B 站看到一个视频，下面有个人回复
我想说，用 js 写出来的 web app，包括 react native 这种混合开发 app，都是**！ js 想染指移动端饿死 java 和 oc 想太多了...谷歌自家推出的 flutter 想跨界移动端能否成功都遥遥无期，js 靠边站站
我寻思，这 APP 交互性的好坏难道不是由开发者的水平和产品设计决定的么。而且如果我只是一个活动页，或者简单的论坛（早期的牛客网）真的有必要完全用原生么（从性能、开发周期和后期迭代权衡来看）？
在后面的对线中，他提出要比比 rn 和原生的性能，我就怼了句你真的理解 rn 要解决的问题么？，然后收到了如下回复。
页面出现了，网络请求成功了，对你来说就是一个 app。。。。笑死
emm...第一次见到，原生开发者对 rn 这样的跨平台 UI 框架存在这么大恶意的
 |
1
yejinmo 2019-12-12 13:34:10 +08:00
真正担心的是会被抢饭碗吧
|
 |
2
lagoon 2019-12-12 13:37:50 +08:00
没必要开地图包。
作为一个原生 Android 码农，当年我就学了挺长时间 RN，如今我在写 Flutter 的个人项目练手。 web 也学了下，但无奈感觉特别混乱邪恶。暂时没有学下去。 个人觉得 Flutter 是极好的。 |
|
3
lagoon 2019-12-12 13:39:44 +08:00  2
不过身边确实有，不学，但又恐惧，于是整天和我说没用的人。
我觉得学，终归是有用的。 比如当初学 RN，虽然我没打算继续下去，但相关知识，令我学习 Flutter 事半功倍。 |
 |
4
wangyzj 2019-12-12 13:40:14 +08:00
前端写一个 JsFlutter 就好啦
|
 |
5
janus77 2019-12-12 13:40:53 +08:00 1
我觉得最后一句暴露了你的观点……客户端开发和浏览器页面开发真的不是同一个东西，UI 占的比重是很大但绝不是全部
所以如果你只把他当做一个 UI 框架，那他就只能做（或者说擅长做） UI 能做的事 而且你举的例子也恰好说明了这一点（那就是一个纯 UI 场景） 那么作为纯客户端开发人员，对他的其他地方予以诟病，是完全有立场也有论据的 |
 |
6
okwork 2019-12-12 13:42:22 +08:00 via Android
下载 APP 的，必然是看重性能和体验的，一般应用 web 就够了，混合开发夹在原生和 web 之间，不伦不类，大多沦为外包忽悠客户的速成 app。没有品质的应用和开发模式，确实不看好
|
 |
7
NSAtools 2019-12-12 13:45:28 +08:00
各位大佬，flutter 现在坑还多吗？
|
 |
8
Hanggi 2019-12-12 13:46:37 +08:00
这就跟当年经典的傻瓜相机和交卷相机发展一样。交卷商会说，你们傻瓜相机画质差、解析度低、功能少、性能差，跟我们专业的交卷相机比差了远了，你们以为能拍出个照片、有眼色就是相机吗，傻瓜相机就是傻瓜。
后来的事情大家都知道，事实证明交卷相机死得很惨。 这个人与其说觉得跨平台 app 方案是垃圾，其实是他希望他们是垃圾，这样他还尚有坚守自己那点卑微的自尊的理由。如果 flutter 等发展的越来越好，这个人的言论还是不会变的，因为他已经把自己定义为原生开发者，觉得自己是贵族，尔等草民怎能和我伟大的原生开发相提并论。 |
 |
9
MorningStar0 OP @janus77 确实 rn 有不少值得诟病的地方（最浅显的例子：那比如调试工具过于分散，开个网页的同时还要开个 as。），但是 RN 也凸显出 MVVM 这种模式在开发客户端的时候带来的开发优势（终于不用 findbyId 了）。
|
 |
10
youxiachai 2019-12-12 13:54:51 +08:00
其实...如果你玩懂了..wpf..现在那些什么 rn 和 Flutter
你会发现.居然读一下文档.就能上手.了... |
|
11
MorningStar0 OP |
 |
12
palxie 2019-12-12 14:23:57 +08:00
也不知道在争什么, 反正我觉得现在用 rn 开发比原生开发香一些
|
 |
13
Bijiabo 2019-12-12 14:26:48 +08:00
前年想在公司用 React Native 做特定业务场景的需求（毕竟可以插件化加载，香），开会的时候大部分原生工程师都在喷 React Native 性能差。
做了一年，拿着手上做出来的东西回过头来看，这个和个人水平还是有挺大关系的。有的工程师嘴上一套一套的，实际上手让他拿原生来写个 React Native 做出来的交互，他都不知道怎么实现。 工具始终都是工具，主要还是看人吧。 |
 |
14
damngood 2019-12-12 14:58:23 +08:00
看类型, 有些类型的 App 用 rn flutter 就够了, 而且还可以跨平台.
有些类型的 App, 比如对 UI, 对性能都有比较高要求的可能就还是原生保险点. |
 |
15
zhbzhbzhbz 2019-12-12 15:06:28 +08:00
@lagoon 那请问写一个类似体育比赛计分的界面（比如简单篮球裁判工具，含在线功能），这种如果有非常规 ui 控件的，并且需要在 ipad 和安卓平板上使用的适合用 RN 还是 Flutter ？~
本人是 Android 开发，也会一些前端 |
 |
16
guokeke 2019-12-12 15:14:49 +08:00
使用某工具或者说某语言而产生过分的优越感，这种莫名的自负伤害太大。而且 rn 也不是不能和原生混着写, 有原生 app 开发经验反而是优势。
|
 |
17
Vitali 2019-12-12 15:15:16 +08:00
作为原生 Android 开发，非常乐意接触 RN 和 flutter，鸟大了，什么林子都有，不要介意
|
|
18
lagoon 2019-12-12 15:22:11 +08:00
@zhbzhbzhbz 我又不是 flutter 大佬。我能说：什么熟悉用什么吗？
|
 |
19
lancelock 2019-12-12 15:24:31 +08:00
我想学 swiftui，但是热度太低了，没啥资源
|
 |
20
hoyixi 2019-12-12 15:28:43 +08:00
老板主要考虑成本，包括人力成本、人员招聘成本、后期维护成本。
同样，一个技术有没有生命力，使用者的成本也是一个大因素。 |
 |
21
Freeego 2019-12-12 15:41:26 +08:00
@lancelock 主要是最低支持 iOS13，想要流行至少要等 iOS15 出来，再加上国内很多公司连 swift 都没用上……
|
 |
22
so1n 2019-12-12 15:42:06 +08:00
还是以需求为准.就像有些类型 APP 不用接触平台底层,用 RN 和 flutter 一套代码就能搞定,时间成本少了很多
|
 |
23
FuryBean 2019-12-12 15:59:04 +08:00
这个世界很复杂，每个人都有自己的看法。要包容别人的看法，建议不要因为看法不同就引起自己的情绪起伏。
你遇到的这个问题类似于网络上电动汽车和传统汽车的对比和争论，有空可以去了解下，两方的观点都非常有趣。 |
 |
24
nicevar 2019-12-12 16:11:05 +08:00
原生确实非常不适合用来开发活动页面一类，但是 RN 这种也不是什么很好的选择，这种情况 RN 远不如 H5 配合原生优化来做
|
 |
25
lzihua 2019-12-12 16:11:06 +08:00
如果原生平台生态没有发展。就算垮平台支持了，意义何在。
|
 |
26
murmur 2019-12-12 16:19:47 +08:00 via Android
flutter 是人 间 之 屑
react。native 是好东西 |
 |
27
KuroNekoFan 2019-12-12 16:27:09 +08:00
rn 好
flutter 确实应该扫进垃圾堆 |
 |
28
noobcoder1 2019-12-12 17:01:36 +08:00
苹果都要下架 H5 应用了 .....
|
 |
29
closedevice 2019-12-12 20:38:37 +08:00
工具因人而异
|
 |
30
neoblackcap 2019-12-12 21:09:08 +08:00
@Hanggi 你这个类比是不对的，事实上应该用专业相机对比傻瓜相机，数码相机对比胶卷相机。胶卷相机是被数码相机击垮的，不是被傻瓜相机。傻瓜相机也用胶卷啊。
回到移动端，事实上对交互以及性能有要求的应用，还是会选择原生的。基于网页的应用也会占据一大部分市场份额。其实这有点像汽车市场，你总不可能拿一辆卡罗拉去拉货吧？ react native 看似美好，坑也不少。有些 bug 一样需要了解对应平台的人去解决。毕竟它不是原生的，平台商对它的支持肯定不如平台原生的。 |
 |
31
secondwtq 2019-12-12 21:21:39 +08:00
Flutter 跟 JS 有关系么 ...
硬要说的话大概是 Flutter 一大作用是一套代码到处运(tiao)行(shi)，然后恰好这一行目前的领导核心是 JS 我寻思最早叫唤一次编译到处调试的不是 Java 么 ... |
 |
32
maxxxxx 2019-12-12 21:28:53 +08:00
RN，flutter 这种技术对开发者可能有好处，但是对用户来说真的是粪坑。
|
 |
33
coolmint 2019-12-12 21:33:05 +08:00 via Android
公司起了个新项目，我一个人做，果断 flutter 了，虽然还不是非常非常熟练，但上手之后很快也进入基本的开发状态了。
|
 |
34
YenvY 2019-12-12 22:43:57 +08:00
所以这是哪个视频呢
|
|
35
murmur 2019-12-12 22:46:42 +08:00
@noobcoder1 这意味着应用程序的核心特性和功能必须包含在软件的二进制文件中，而不是通过在批准的应用程序之外引用用户（包括使用 HTML5 ）来实现
flutter 和 rn 包括 uniapp 都逃不脱干洗，真要严格执行除了纯源生应用都得死 |
|
36
murmur 2019-12-12 22:48:46 +08:00
按这么说又是源生安卓和源生苹果的春天，先死的是 flutter，rn 也不会好过，html5 只能拿来开发企业应用，反正不需要商店，微信的话语权将无限大
太可怕了 |
 |
37
Pastsong 2019-12-12 22:52:38 +08:00
毕竟饭碗决定观点
|
 |
39
qinfensky 2019-12-13 02:13:11 +08:00 via iPhone
我最近要舍弃 React Native 了，太可怕， 我升级了 macOS 10.15 后，旧有代码编译报错，烦死人，又没空升级，如果是原生，就不会有这个错误发生，要业务改动随时改动。
|
 |
40
weixiangzhe 2019-12-13 09:07:44 +08:00
@qinfensky 是 apple 可怕，系统升级连带 xcode 升级，xcode 升级代码编译不过；系统不升级，手机升级了，调试不了
|
 |
42
hyy1995 2019-12-13 09:24:31 +08:00
原生开发者对跨平台框架有恶意是正常的，毕竟涉及到抢饭碗问题。现在很多中小型公司都不会招 Android 和 IOS 开发的，节约成本，有前端人员就够了。
“react native 这种混合开发 app”——话说 rn 不是 native app 么，跟混合 app 是两码事啊，混合 app 是套的 webview，性能肯定不行，但是 rn 这种 native app 编译出来的就是原生应用啊，虽然那些个插件对比原生确实还是存在差距，但差不太多。。。 |
|
43
hyy1995 2019-12-13 09:26:02 +08:00
另外，跨平台已是趋势，无法阻挡，可能再过几年，就能真正替代掉原生开发。可以想想几年前的前端框架，跟现在的差距对比。。。
|
 |
44
oahebky 2019-12-13 09:37:46 +08:00
原生+web 是必然趋势。
原生用于接广告时满足广告投放客户的“精准投放”需求。 web 用于快速迭代、试验新产品、新活动。 从大型公司来看，app 内部换成: +-------++-----+ +--------+ | java | | 框 | | Web | | UI | | 架 | | app | +------+ +-----+ +--------+ 也是一种比较聪明的选择。 app 框架层可以在 android 和 ios 适配。 未来有新系统加入开发起来省了一半以上功夫（所有 feature 不用从头一个一个 merge 过去，只要适配好框架层就 OK 了，用黑盒、白盒测试框架也可以直接保留） |
 |
45
BigDogWang 2019-12-13 09:44:41 +08:00
短期内应该是不会学这些东西的，对 UI 开发已经了无兴趣了。
|
|
46
BigDogWang 2019-12-13 09:47:28 +08:00
不过还是不太看好 flutter。原生+网页混合开发不错
|
|
47
damngood 2019-12-13 09:48:38 +08:00
@hyy1995 我大部分时间是 iOS 原生开发, 也用 RN 开发过两个 App, 无论是产品体验还是开发体验, 和原生开发还是有不小差距的.
产品体验有差距当然也有可能是我前端水平不够的因素在里面, 但是开发体验还真是没得比. 几年后的情况还比较难说, 像现在的 SwiftUI 或者是 Jetpack Composer 这种技术如果成熟了, 而且有其他平台的 port, 那开发者估计还真不太愿意用现有的这几种跨平台的方案. 据我所知, 至少 SwiftUI 已经有人着手在做其他平台的移植. ( 我很期待这个 ) |
|
48
murmur 2019-12-13 09:52:46 +08:00
@hyy1995 但是 apple 这次的目的很明显不是解决性能问题，而是为了解决马甲包和非法应用的问题，那么具有动态性能的框架和 app 都会被下架，h5 自然要杀，react native 也跑不掉
以前针对博彩、成人内容这些也有严打，但是很明显力度不够，你有检测方法别人就有开关机制，所以会不会直接封框架，就检测有没有用 rn、cordova 这些 |
|
49
qinfensky 2019-12-13 15:11:03 +08:00
@weixiangzhe 对我造成了困扰，我还是换个稳固方案好了
|
 |
50
behanga 2019-12-13 15:46:59 +08:00
rn 最主要解决的问题：
1.人力资源问题，一个功能两端实现，两份人力，两份工资。 2.热更新，不依赖 app 的发版。 以后长期都会是原生开发，rn，hybrid 共生的环境。这些都是因为业务形态做的取舍，没有谁将会取代谁的情况。 |
 |
51
Balthild 2019-12-13 16:17:40 +08:00
@janus77 首先 RN 和 Flutter 根本就不是什么“浏览器页面开发”，其次它们都可以调用平台原本的语言来实现系统相关的非 UI 特性
|
|
52
secondwtq 2019-12-13 17:55:17 +08:00 1
@murmur 我的理解，Apple 此举的主要目的，通俗地说就是禁止热更新（应用送审后行为不能改变，或者说与外界通信内容仅限于数据，不能传输程序）。
还有一种可能是遏止非原生框架（包括“H5“）的大量使用对体验的劣化，不过我个人偏向于前者。 所以理想情况应该是封有热更新行为的应用，但如 #48 所说这并不现实。之所以单独拎出”H5”，以及专门扯了一堆 WebKit JavaScriptCore 之类的，是因为使用“H5”和热更新这两者之间有一种奇妙的强关联，基本一抓一个准很少有错的，事实上就官方声明来看已经对“H5“采取了一刀切的手段。 但是我不认为所有类似的跨平台框架都在 Apple 的目标之内，因为”跨平台”和”热更新”根本就是两个正交的需求（虽然可以用同样的技术手段解决）。跨平台框架可以不做热更新。并且理论上，跨平台框架也可以做到把所有东西塞到一个 binary 里面（只是目前可能还很少这么做），至少可以满足技术上的要求（不运行 binary 以外的代码）。 “热更新”（或者广义上的执行非自身 binary 中的代码）也不是禁了已有的框架等具体的技术就能禁的，因为“数据”和“程序”其实是无法区分的。甚至一个程序有没有“热更新”行为也很难界定。 最极端的情况是有实力也有需求的大厂自己造私有的跨平台 /热更新的框架。想到这最搞笑的是，如果真有人用这种方法绕过热更新限制，那就没法做 JIT 的现状和某些华而不实的大厂的真实水平来看，可能最后体验还不如 H5 |
 |
53
loginbygoogle 2019-12-14 05:48:11 +08:00 via iPhone
区区 web 前端也想学 flutter，可能不配。
|
|
54
noobcoder1 2019-12-16 16:22:22 +08:00
@loginbygoogle 这年头 已经没什么门槛了 只要认真学 都能很快能上手
|
Select Language