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

[nohup]

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

[Lisk]

不得不说楼主隐藏的很深，其实你早就看那个前端不顺眼了
先开一个嘲讽贴说 react 不如 vue，然后如期收到回复
再把这个贴子给那个前端看，间接打他的脸
获得了证据后马上通知管理层，让前端背锅
最后再找一个大厂的人盖棺定论，666

[az1996]

react-virtualized 了解一下？

[mrcode]

这帖子一开始就是抱着黑公司的心态去的吧😂

[l00t]

@Lisk #201 城市套路深啊

[mrcode]

@Lisk 不能同意更多

[golanger1]

贴个 react-virtualized 链接 https://github.com/bvaughn/react-virtualized

[Asice]

没完全了解源码的人敢说的这么绝对就不是个合格的程序员

[HENQIGUAI]

围观吵架，好过瘾，学到了，感谢各位。

[anmie]

这波操作真的秀，楼主有点人性就把公司名暴露出来，我们好拉黑

[v2chou]

翻译一下： 前端不是我开的 是管理层开的 和我没有关系

[DXpro]

牛逼 牛逼， 前端从讨论到被辞退 见识了...

[lucahan]

@Lisk 十分赞同。刚开始看这个帖子的时候，我还以为楼主是带 vue 和 react 的节奏，没想到最后居然搞得让前端离职了。只能说楼主这种人很可怕了。

[keysona]

可怕

[ucanuup]

@Lisk 同意，但就事论事，前端这么菜，被炒是应该的。

[tianyou666shen]

一般人处理问题都是最轻松的方式
找个朋友问问 难道比 大会上决定换框架重构 还难吗
非得要闹到高层介入开除人 然后才想到朋友?
所以楼主为什么这么干?
为什么最后论坛框架撕了 前端人走了 大家贡献方案了 你最后收功劳了
这也太优(厚)秀(黑)了吧

[beginor]

这算不算是杀了一个程序员祭呢？ 🦍

[Jimrussell]

这个时候怎么不说菜是原罪了？楼主这波秀到头晕的操作，我倒是觉得没什么问题。

楼主那个 ex 前端同事，估计就是又菜脾气又大然后比较喜欢甩锅的那种。同为打工阶层，我反正也是受不了这种前端作为同事的。

[TomVista]

现在开始讨伐楼主了,楼主你说,你让我们说什么好呢?

[leinov]

好怕怕

[VoidChen]

好过分哦，欺负搞技术的人都比较单纯吗