这是一个创建于 1952 天前的主题，其中的信息可能已经有所发展或是发生改变。
因为几个项目下来，我们发现前端的应用过于卡顿，甚至还不如上一版本 JQuery Easy UI 做出来。在项目经理的会议主持下，我和前端同学在会议上就React 是否符合我们需求的问题充分交换了意见，最终会议决定放弃 React，转向 Vue。
具体原因如下：
我们应用需要每个 tab 内容显示 1000 个列表条目，每个条目显示一个文本状态和背景颜色，1000 个条目里随机每秒有一个改变文本状态。
之前有一版是用 JQ 的。JQuery 做出来的就初次只卡顿 2s，而 React 作出来每点击一次 button 却要卡的四五秒。经过前端深入对 React 研究之后，他认为这是 React 的缺陷-->无法很好地解决高频率渲染大量组件内容。
为什么无法解决呢？我不是前端，我这里拷贝一下前端的原话：
因为 React 在进行状态更新的时候，会进行判断每一个 listitem 的状态是否有改变。当然一两个组件这样就没啥问题，但是要是有 1000-1500 个小方块同时显示，而且每秒还要更新客户订单量，这样统计就会很卡了。你可以自己试一下，for 循环 1 到 1000,只输出一个文本，都会卡成狗屎，更别说 React 判断过程中不只判断一个 prop 属性呢，他要判断 N 个属性，你要在 1000*N 的判断之后，才进行渲染呢！我一开始就说用 Vue 会比较好，React 在 ERP 有嗯用完全搞不定那么多高频率的渲染需求的。“
而且我也觉得用 React 的大部分都是为了 CRUD 吧？如果像一些实时的高频率的刷新，抱歉，我和前端没看到哪一个大厂用 React 来做，感觉真的卡成狗屎。既然前端觉得 Vue 很 ok，那就让他去试试。
所以，各位认同 React 不适合大数据高频率的论点吗？
第 1 条附言 · 2018-12-22 15:55:49 +08:00
各位，这不是“水平不行怪框架”，这是取舍的问题。
假如项目时间给够，钱给够，你让我用 JQuery 去开发，渲染细节细腻到每个 DOM 层面，那都是没问题的，而且我也不用去看什么源码，什么最佳实践 。
如果 React 解决问题不那么直接，直接上手还有这么多坑，难道锅全是开发人员背吗？你要追求开发体验，语法优雅，项目重构方便，而对于用户来说界面响应、访问速度才是主要的，其他都是瞎扯
假如项目时间给够，钱给够，你让我用 JQuery 去开发，渲染细节细腻到每个 DOM 层面，那都是没问题的，而且我也不用去看什么源码，什么最佳实践 。
如果 React 解决问题不那么直接，直接上手还有这么多坑，难道锅全是开发人员背吗？你要追求开发体验，语法优雅，项目重构方便，而对于用户来说界面响应、访问速度才是主要的，其他都是瞎扯
第 2 条附言 · 2018-12-23 23:37:45 +08:00
我们已经辞退那位前端同学了，他也表示理解，毕竟项目出问题了总要有个说法，看有 V 友提供的 demo 都很流畅，看来还是人的问题是主要的。
抱歉给 React 抹黑了，其实 React 应该还是很 NB 的
抱歉给 React 抹黑了，其实 React 应该还是很 NB 的
第 3 条附言 · 2018-12-24 09:15:09 +08:00
我和一位在大厂的朋友沟通联系，他花了一晚上就把项目调优好了，至于辞退也是管理层的意思，我和前端都做不了主。。
 |
301
ala2008 2018-12-25 12:47:54 +08:00
我们公司 vue 和 react 并行。。
|
 |
302
Hconk 2018-12-25 12:57:46 +08:00 via Android
娱乐圈又添新秀
|
 |
303
sunboy911 2018-12-25 13:21:36 +08:00
楼主不怀好意
|
 |
304
xuhp 2018-12-25 13:26:22 +08:00  8
“经过技术选型研究，我们放弃了 那位前端同学”
|
 |
305
bk201 2018-12-25 13:28:59 +08:00
所以技术人员不要太关注技术，稍微关注下空气。
|
 |
306
cheesemp 2018-12-25 14:09:34 +08:00
首先站在这个问题是真实的情况下:
各位同行, 别当嘴强王者了. 大家都是混口饭吃, 搞的人家被开了, 何必呢? 一句话. 找的是前端工程师还是前端科学家? 工程师的目的不就解决问题吗? 站在同行的角度, 以自己最优的选择出发是最正确的, 那怕他用 JQ, 他能搞定那就没问题.其它的都不重要. 何况人家用 react 也实现出来了. 这起码就够格了(你第一版就完美了?) 用 VUE 就政治不正确了? 那做 Z F 工程的兼容 IE 不是要送去停车场了? 只会嘴上 BB, 需求方嘴上说的好听. 表面上的都是 冰山一角. 想换的托词一堆. 别人也不想听. 能解决问题就行. 假如这位老哥. 换完 VUE 还是搞不定. 那就另当别论. |
 |
307
jimrok 2018-12-25 14:10:26 +08:00
放心，过了这坑，还有别的地方能绊倒你们的前端。
|
 |
308
kingcc 2018-12-25 15:26:20 +08:00
楼主真是厚黑学专家啊…太可怕了
|
 |
309
Geniusssssss 2018-12-25 19:02:37 +08:00
前端问题不是很多 楼主你嘛 适合当管理层 别当程序员了
|
 |
310
a4854857 2018-12-25 19:13:46 +08:00
卧槽。我就说这个帖子好几天了有什么好吵了。实在是忍不住有点进来看了一眼。。。这剧情实在是。。。
|
 |
312
shiye515 2018-12-26 01:59:33 +08:00 via iPhone
拉不出屎赖地球引力不够
|
 |
313
tatelucky 2018-12-26 09:37:44 +08:00
坐观 react vs vue 我预测 react 赢 来自后端的观察
|
 |
314
s609926202 2018-12-26 09:41:41 +08:00
贵司不会就一个前端吧，，人非圣贤孰能无过！
|
|
315
s609926202 2018-12-26 09:52:12 +08:00
还有，被辞退了，还表示理解......可能前端同学早就不想干了、、
|
 |
316
lzszone 2018-12-26 11:38:57 +08:00
就事论事的说...
1000 条不多呀... 不至于到优化的层面吧.. |
 |
317
frozen2013 2018-12-26 14:16:25 +08:00 via Android
本来可以纯粹是技术讨论，被题主搅成办公室政治，还 TM 放在网上嘚瑟。
后悔回你的帖。。。 |
 |
318
RRRSSS 2018-12-26 15:23:45 +08:00
Angular??
|
 |
319
lingyi95 2018-12-26 21:11:10 +08:00
@codermagefox 我想不通，我刚写了个 demo，一万个色块，同时随机变色，也不卡 5 秒啊，react16
|
|
320
lingyi95 2018-12-26 21:11:52 +08:00
我觉得什么优化都不做也不会卡 5 秒
|
 |
321
javascr1pt 2018-12-27 09:54:02 +08:00
心疼，真的心疼
|
 |
322
joinmouse 2018-12-29 17:44:51 +08:00
难道作为一个前端不是应该想想在 react 的框架上学会去怎么优化嘛
|
 |
323
momocraft 2018-12-29 18:20:28 +08:00
@cheesemp 遇到个不被 (还没被) 自己连累的框架未必能叫"解决问题"
写不出东西也不要推给 "我是工程师不是科学家", 不知道的以为是让人造火箭呢 正经分析过性能不给框架抹黑的人愿意和这样的共称工程师吗? |
 |
324
n313893254 2018-12-29 22:27:03 +08:00
看了这个帖子，以后不敢在同事面前 diss Ember.js 了 [捂脸
|
 |
325
Xek1n 2019-01-04 16:29:01 +08:00
大厂的朋友这么 nb 嘛…花了一晚上就全调优 ok 了？
|
Select Language