前端把页面做得很卡怪 React，说 Vue 才能解决问题，现已被辞退
点击阅读原文
3
前端把页面做得很卡怪 React，说 Vue 才能解决问题，现已被辞退
这。。。。
前端把页面做得很卡怪 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 不适合大数据高频率的论点吗？
25 条评论
“Lisk:不得不说博主隐藏的很深，其实你早就看那个前端不顺眼了
先开一个嘲讽贴说 react 不如 vue，然后如期收到回复
再把这个贴子给那个前端看，间接打他的脸
获得了证据后马上通知管理层，让前端背锅
最后再找一个大厂的人盖棺定论，666”
赞 +7
本来就是什么顺手用什么，不是框架不好，别人都说是讨论，但非要拿证据才能用自己想用的，那就只能瞎扯一个问题，一个小前端能力有限，不是每个框架都能解决每个问题，找个合适自己的就好了，难道你找对像都要听别人说那个好就追那个吗？
赞 +4
react长列表渲染要讲究技巧，vue不使用技巧的情况下渲染长列表一般不会遇到太大问题。不追求状态维护一致性（比如redux状态管理:子组件dispatch新状态到store,store变化后长列表更新）,只处理操作的列表项组件（通过setState来局部更新组件）react是不会有性能问题的。但是追求状态维护一致性就会遇到问题了，这个时候就需要很多的优化技巧。
赞 +4
典型的杀程序员祭天 ，后台把所有锅推得干干净净。 什么列表条目有 1000 行。我算你一行 10px 高度好了。手机 2000px。也就是说手机屏幕 5 页。后台做了分页了吗？
赞 +4
可能还不太懂react的渲染模型吧，可以在shouldupdatecompnent或者使用purcompnent组件，总体来说就是防止重复渲染，用js做判断，js可是很快的
赞
最喜感的是原文中的，“用jQuery实现的只卡2s”，2333
赞 +12