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

[nohup]

回复 by 前端

@reus 我最了解前端了，用几个数据结构的术语就可以说些模模糊糊的话，别人不理解那就是理解能力有问题，而不是自己说话不清不楚

[reus]

@nohup 例如更新第 700 个，在各个结点组件的 shouldComponentUpdate 里判断，前 500 个不需要重渲染，后 500 个需要。后 500 个里面，前 250 个需要重渲染，后 250 个不需要。250 个需要重渲染的里面，前 125 个不需要，后 125 个需要。递归下去，到第 700 个，需要调用的 shouldComponentUpdate 次数是 log(2, 1000) * 2，不需要一个个比较。

[hlwjia]

@hlwjia 好吧，vimeo 是被墙的，就这么招吧。能翻墙的就看看吧，看不了没办法啦

[so898]

明天会不会因为 SEO 转回去……

[reus]

@nohup 所以说菜鸡就是菜鸡，懂的人，说到“二分”，就应该领悟了，知道要用二叉树去表示组件，从而高效地判断需要更新哪里。菜鸡呢，说再多也理解不了，反而怪说的人没说清楚。

[251243021]

纯属写法问题.不怪框架,顶多 vue 更友好而已

[kimown]

项目性能考虑，需要换语言，换框架，地球上肯定有案例的，但人能力不行，水平垃圾还做开发，怪语言，怪框架，也是有的，lz 你是上一类人，还是下一类人呢？

[learnshare]

这个性能瓶颈并不能怪哪个框架
是需要自己优化数据量、数据结构或者呈现方式，甚至需要选择一个脑子更好使的产品经理

只渲染可见部分，就是个不错的优化方式。随手搜到的文章：
https://zhuanlan.zhihu.com/p/41237949
https://zhuanlan.zhihu.com/p/26022258

[nohup]

回复 by 前端

@reus “那就只有那个元素路径上的 shouldComponentUpdate 会执行”这段话产生了很多歧义，是 SCU 返回 true 值，还是 SCU 压根就不调用，还是你在外面类似 redux 套了一个高阶函数？
动不动说别人菜鸡，建议你看看自己说过的话逻辑通不通，说那么模模糊糊的话谁可以理解的了？你这种说话调调就像 ：
React 可以加个二分查找来优化，用树来表示列表(是组件层次的树形还是 model 的属性?)，只有需要更新的元素才会执行 shouldComponentUpdate(那到底执不执行?你干脆说会进行渲染不行？)

说的好像只有你会数据结构一样，你当然没有义务完全一步步说的清楚，但是说话歧义这么多，是不是该抽空检查了一下自己？

[hualongbei]

Talk is cheap. Show me the code.

[duzhihao]

难道我们开发产品是为了证明 vue 和 react 谁牛逼。别开玩笑了。

[dremy]

可回收（复用）列表了解一下，1000 多个元素一般不会是一屏全部展示出来的吧，那只 diff 和渲染可以看到的列表元素就好了，几十一百个元素的话肯定不会有问题

[dremy]

@dremy 和安卓的 recyclerview 或者 iOS 的 UITableView 相同的原理

[sunnyadamm]

围观一下😂😂😂，不做评论

[creanme]

想看 demo。。。简单演示下就行。

[wu67]

@dremy 还真有那种一页列出一千多两千条的垃圾需求, 产品就是这么要求的...明明告诉过他这要把整个表都列出来了...

另外上面某人说话戾气真大, 有技术经验确实是可以骄傲的资本, 但不意味这你可以随意鄙视贬低别人, 没几个人是生而知之的, 说的好像别人不能见微知著就是垃圾一样

[Lax]

一个项目用 vue，有一个列表，10000 条数据的列表，首次打开和更新会都感觉卡顿（排序+渲染接近 1s ），减少到 5000 条数据时感觉卡顿不明显。
用浏览器 profiling 工具看到大部分时间在遍历 dom 的操作。
这类问题解决方法是只把需要展示出来的添加到页面。我用了这个库： https://github.com/Akryum/vue-virtual-scroller
换成 vue 之后你们 1000 条数据时的问题，可能会延缓到 5000 条以后才遇到，也算解决了问题。但是我并不认为 react 会“不行”，可能不适合你们使用。

[murmur]

@Lax vdom 的框架 batch insert 都要趴窝
还得 jquery+template 一次生成字符串一次插入搞定

[reus]

@nohup 那你们前端知道用 react 怎么实现了没？

[will0404]

你的 listitem 组件可能很复杂，也可能很简单，1000 个可以说多，也可以说非常少。
无论如何，一秒钟改变其中一个的状态，基本上不会造成性能问题，别说 4s，1s 都不可接受。
我刚刚试了一下每一秒改变 10000 个组件的状态，React 每次重新渲染都少于 400ms。当然我实验的组件很简单，它没有子组件。
我给你提供个思路，ReactDevTool 可以看到每次操作哪些组件被重新渲染了，显然，你有太多组件重新渲染了，实际上每次只需要重新渲染一个。一般情况下，用 shouldComponentUpdate 就可以解决。但我不知道你的情况有多复杂，就不多做评论了。
不过我看了下上面的回复，不觉得这是 React 的问题。