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

[kcats]

试试 react-virtualize 吧, 大的 list 在哪渲染都会有问题. 可以参考下移动端 native 的 ScrollView 和 ListView 的实现.

[Nicoco]

果然是 Web 前端娱乐圈，佩服佩服。

[wangxiaoaer]

各位都是大佬，写个 hello world 都能把编译原理学透彻。

同样一拔人，即使是菜鸟，不做优化，一个框架比另一个快，这起码能证明其中一个在易用性上甩另外一个几条街吧，也能证明另一个的学习成本高吧。

那么问题来了，为了学框架而学，还是为了解决问题而学？


楼主遇到的问题，轻易就用 vue 解决了，用 react 需要额外工作，从这个角度，站在楼主的立场，react 还有什么用的必要，因为难？因为用起来逼格高？

[ahonn]

@wangxiaoaer #143 这里楼主并没有证明能够轻易用 vue 解决，我到
的理解是目前大部分人写的代码还是很难达到框架不够用的情况。如果有，解决方法只能是自己定制一个框架，而不是换框架解决。

[xmsz]

很理解楼主心情，作为前端小白我也很想知道，在这里应用场景下，到底哪种更合适，并且为什么。
可惜，大家都是来骂，都没有实践

[tyrealgray]

楼主，你们公司的前端是坑啊，这个和框架没有关系，只是他们单纯的懒不想深入优化而已。别被带沟里去了

[dawniii]

@reus 大佬 我很少写前端，不过对你说的组织二叉树很感兴趣。假如把后端返回的列表数据用平衡二叉树来组织。那 react 的 render 函数可以有区别的搜索替换子组件吗？还是说就是在 render 里面简单的中序遍历二叉树呢？假如后端返回的 1000 行列表其中 800 行都变了呢？是不是组织二叉树结构也没啥优势了？

[reus]

@dawniii https://codesandbox.io/s/wnk25xxn8 大致是这样。

Node 类的 shouldComponentUpdate 需要根据你的数据更新策略去写

[royzxq]

开始了开始了， 对于这种列表项目，建议只渲染可见部分。
最耗时的大部分情况下是浏览器渲染， 当然， 代码写的炸导致时间复杂度爆炸的情况下另说。
总之， 能只渲染可见就别渲染全部。 能对之前的 dom 复用就对之前的 dom 复用。

另外想请教一下 @reus 大佬一个问题。B 站弹幕列表全部渲染的情况下，对弹幕进行排序，您能做到的最快时间是多少呢？ 同时旁边还有一个播放器在进行播放。

[royzxq]

#149 的后半部分表述不太清楚，补充一下。

B 站右边的弹幕列表现在是只渲染可见部分。 那么如果渲染全部列表（假设 1000 条）的同时旁边有一个视频在进行播放， 那么更换一次排序方式， 到 DOM 重新渲染完成需要多少时间呢？

[reus]

@royzxq 现在的需求不是只渲染可见部分，而是可见部分就有几千上万个元素，只更新其中一部分，如何让开销最小，是这个问题。vue 是更新哪个元素的数据，就触发哪个元素的重渲染，所以不是全量更新数据的话，是不需要遍历元素去检测的。而 react 是不带这一部分的，想要的话可以用 mobx，或者自己实现更新逻辑。某些前端不知道怎样实现，反而怪 react 有缺陷。

[reus]

@royzxq 那就是一千次字符串比较，和最多一千次的 innerText 更新需要的时间。

[StephenHe]

上家公司后端 net 写了个接口很卡，优化了好久才解决，后来领导觉得新模块换成 java 写。

[dawniii]

@reus 这样的话好像得事先自己知道列表中那些变化了，才好写 shouldComponentUpdate，不然落到 elems 长度为 1 的时候再判断就还是全列表扫描了。

还有就是列表里面有 800 个变化了，这个方法貌似也不合适。可能是我哪里理解的有偏差。。。

[weakish]

@wangxiaoaer 但是换 vue 也有成本的呀。而且换了后又碰到类似问题怎么办？再换别的？

[secicl]

@so898 看到您的回复很感兴趣的问一下（与楼主的情况无关），请问 SEO 这块，vue 与 react 方面会有较大差异吗？有什么最佳实践吗？

[maplelin]

@secicl SEO 本质是搜索引擎爬取页面的 html 结构和数据，由于 react 和 vue 都依赖 js 动态渲染 DOM 和数据，所以对于 SEO 普遍不友好，在这方面两个框架都没有太大差异。目前这种 SPA 的 SEO 优化的主流解决方案一般是预加载和 SSR （服务端渲染），提前得到一个数据较为完整的页面提供给搜索引擎爬取。

[yc8332]

大部分前端没有优化、性能提升的意识。。。就是做做界面而已。。。就拿最简单的按钮点击，他们没有人主动做禁止连续点击的，如果是出页面的话，都是连续点击出 N 次，请求也是发 N 个。。

[LeoEatle]

利益相关，目前在鹅厂用 React，并且我所在的事业群大部分都在用 React。

认真回答一下这个问题，楼主提出 React 是否适合大数据量的、高频率的 DOM 变换场景，我觉得依然适合。并且 Vue 不见得就能解决这个问题。

大数据量、高频率的 DOM 变换的确是前端的难点，React 其实是用框架和语法去简化这种操作，提高可读性，这才是所谓前端框架最大的好处，用 Jquery 甚至原生 JS 实现行不行？当然行，但是你要耗费的时间和精力，以及后人维护的成本，都会变得很大。

那么为什么会出现这种点击一个 button 卡顿几秒钟的情况？先分析一下你们 React 代码中的生命周期钩子，有没有什么耗费时间的操作，有没有使用 shouldComponentUpdate 去判断不需要重新渲染的情况，点击一个 button 想必出发了 state 的更新，是小组件的 state 还是不小心触发了外层？这些都要去分析一下。

另外就算这些都优化到，也确实可能出现卡顿的情况，这是因为 React 目前还没完全支持异步渲染，也就是 React 16 强推的 Fiber 算法，Fiber 算法的强大在于 render 过程可以异步，可以允许中断 render 过程优先响应用户操作，目前 React 16 还未完全放开，但这对这种大数据量的计算渲染性能提升很有帮助。

不过说真的，只有 1000 个列表组件还优化不到这个地步。

[LeoEatle]

@yc8332 这个只能说不同前端水平确实不同，我这边这种请求中禁用按钮的逻辑都是写在组件里的，不可能出现这种情况，否则后台同学也会很难处理