经过技术选型研究，我们放弃了 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 不适合大数据高频率的论点吗？

[robinlovemaggie]

来自某推的#前端娱乐圈

[sSsSsSs]

@Jimrussell
觉得楼主没问题 +1

[andyL]

真的是笑死我了 哈哈哈哈哈，你们公司也真够牛逼的，佩服佩服，真是相煎何太急

[aniua]

开发话说太满，但技术 Leader 不粘锅也说不过去。

[lsvih]

太秀了，这能把人开了

[ben1024]

开人的操作令人窒息

[IWSR]

没代码能说明的了什么，评论区里可真多为了黑而黑的

[wly19960911]

@robinlovemaggie #220 还行，最早的那篇文章看过了，大家都要吃饭的嘛，别砸饭碗了。但是对于精进的人肯定是这样的。

[SEARCHINGFREE]

react 太危险了，现在学 vue 还来得及吗

[isbase]

用 Google 搜索 React large list，第一个就是现成的解决方案

https://www.google.com/search?q=react+large+list&oq=react+large&aqs=chrome.0.69i59j69i57j69i60.4379j0j7&sourceid=chrome-mobile&ie=UTF-8

人家菜是菜了点，直接开了也是。。。

[bxj]

特意登号来说一句，楼上主麻烦报个公司名，好让我拉黑一下。还有楼主你也是和那个被辞退的前端一起讨论决定用 react 的，为什么你没被辞退啊？顺便把 Leader 也一起打包带走吧

[yuxuan]

感觉楼主这个帖子就满满的恶意，本身这种框架谁好谁坏的话题就很有争论，最后还甩出辞退也是管理层的意思，我和前端都做不了主。。 一副我也无能为力的样子 既然有大厂朋友能调 私下里调好了去甩给前端不就行了，明显一开始就是要甩那个前端出来挂人

[miv]

楼主操作很优秀，看了上面很多 v 有回复，想了下。
贵公司就这样开除了前端，真的是有点不厚道了。
这种情况，Leader 难道是吃划水的吗，丝毫没看出来有存在感。
项目出了问题了，那么总需要有人背锅吧？
这前端挺跳，就给他挖个坑好了，死队友不死贫道！
这这这，操作真优秀。

[codermagefox]

看了新 append,突然好内疚

[rabbbit]

厚黑学的完美实践

[leoShen]

楼主如果先进行最后一步，就不会有前面的步骤了吧？
感觉楼主目的不是解决问题，而是要解决同事啊！

[erooo]

我去，项目卡不一起想办法解决问题，直接就辞退，这波操作也是 666。。。整个评论看下来我都分不清楼主究竟是傻还是坏了。。。

[oqpqw]

HDNB

[ashCloud]

好一招借刀杀人，学到了 学到了，大家以后在职场上一定要小心呢。

[gimp]

剧情反转，有点意思