经过技术选型研究，我们放弃了 React，转向 Vue

因为几个项目下来，我们发现前端的应用过于卡顿，甚至还不如上一版本 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 不适合大数据高频率的论点吗？

reus

2018-12-24 09:55:00 +08:00

@dawniii vue 也一样的，所有框架都一样的。所有框架最终的目的都是进行一些 dom 操作，怎样使 dom 操作最少，怎样用最小的开销计算出需要进行哪些 dom 操作，框架是用来做这个事情的。更新 800 个元素，那 dom 操作可能就有 800 次，框架还能怎么优化呢？难道 vue 就不需要一个个去更新组件属性？
所以我就说 shouldComponentUpdate 需要根据你的后端数据怎么获取的来实现，如果都是全量数据，那就只能一个个比较，如果是增量数据，你就有办法让它自动化一点。

hanangellove

2018-12-24 10:26:09 +08:00

@Justin13
“辞退真的秀，研究原型难道是单纯的开发任务么，leader 死哪去了?
如果开发是号称 react 高手，出这种问题确实不该。
但如果是临时学，临时做，出问题那是非常正常的。
出问题了先辞退开发，真是厉害，谁能保证永不出错?
如果有 leader,开发是 react 新手，leader 有主要责任。
如果有 leader,开发号称高手，,leader，开发 55 开。
如果开发的是 leader，号称高手,这种开了确实应该。
如果只有开发，出错就被开，这公司我不敢去。”

赞同~