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

各位，这不是“水平不行怪框架”，这是取舍的问题。
假如项目时间给够，钱给够，你让我用 JQuery 去开发，渲染细节细腻到每个 DOM 层面，那都是没问题的，而且我也不用去看什么源码，什么最佳实践 。
如果 React 解决问题不那么直接，直接上手还有这么多坑，难道锅全是开发人员背吗？你要追求开发体验，语法优雅，项目重构方便，而对于用户来说界面响应、访问速度才是主要的，其他都是瞎扯

我们已经辞退那位前端同学了，他也表示理解，毕竟项目出问题了总要有个说法，看有 V 友提供的 demo 都很流畅，看来还是人的问题是主要的。
抱歉给 React 抹黑了，其实 React 应该还是很 NB 的

我和一位在大厂的朋友沟通联系，他花了一晚上就把项目调优好了，至于辞退也是管理层的意思，我和前端都做不了主。。

[Pastsong]

“ WebApp 卡顿了，有个 1000 条数据的列表渲染很慢”
前端提供的解决方案：我们换个框架把 App 重写一遍就好了

[azh7138m]

@codermagefox 是，没问题，这就是脏检查存在的问题。
可以看下 mobx 的介绍，里面会说为什么会这样，以及如何手动优化。
vue 这里快是因为有依赖收集。

[youngxhui]

你们是怎么得出没有大厂用 react 的？

[tao1991123]

技术不行 框架背锅
virtual-scroller 了解一下

[zsx]

我想吐槽的是，React 不行，OK 我们就当它不行吧。
那突然就把全项目转型 Vue，难道 Vue 就可以？前期调研过了没？
总不能是拍个脑门，“嗯我写的没问题，一定是 React 的问题。本来我就不喜欢 React，干脆重写用 Vue 吧，再不行的话就回到 jQuery。”

[RaymondYip]

实锤的水平不行，才 1000 行就挂

[keelii]

扯什么性能问题，1000 条数据根本没到算法时间复杂度的层面，绝壁操作 DOM 慢了。很多人搞不清出算法层级的性能问题和系统瓶颈的性能问题。

[xichengh]

我们一直用的 react，1000 太不应该了。。。。求例子拿出来

[TabGre]

@Justin13 有什么文章或者教程可以更好理解 react 的范式呀？谢谢

[yljcyct]

吃瓜
虽然作为一个入门的前端不懂什么, 但是我觉得 99.99% 不是 React 的锅

[lisonfan]

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

[pryhub]

我是后端的，坐等结贴

[astrorobbie]

我感觉每个 tab 1000 行数据，真的不至于有你说的性能问题。再排除下别的问题吧。

[Perry]

这确实是取舍的问题。但是你们是怎么如此确定换框架所需要的时间和人力小于解决 performance issue 的时间？在大多数人看来前者往往是费时费力而且在逃避问题。我之前工作上也有过类似的问题，我的建议是每个 lifecycle 所花的时间好好检查一下，5 秒我估计主要时间还是花在更新 DOM 上，应该确认是否只是更新了需要更新的元素。

[kimoCHG]

FYI, https://github.com/vuejs/vue/issues/2000 建议组织会议评估转 Vue 的收益

[witcherhope]

你们前端 React 写腻了，寻思换 Vue 捣鼓捣鼓，过几天怕是又要换回 jQuery

[hlwjia]

我觉得用不用 react 无所谓，适合不适合也是看团队的。

但是你的原始问题是：“所以，各位认同 React 不适合大数据高频率的论点吗？”

所以大伙才出来怼你们的前端。

[hlwjia]

大家都搞技术的都谦虚一点。

我写惯了 react 刚接触 vue 的时候，觉得老难用了。但我不会去吐槽 vue 怎样怎样，因为没深入研究过，就是简单看了文档。

而且还牵扯到常识问题，Facebook 的那帮工程师估计一个单手能打我们 100 个，写出来的东西不会那么不堪的。

很多时候要找自己的问题，别出问题就是别人的锅。

老人家又说多了。。。

[Hypn0s]

换框架就有立竿见影的效果的话说明真是换的值得，让这个去前端继续搞下去不知道会出多少问题

[naturedy]

不要真的把 1000 个 item 全部渲染出来，推荐看下这两个库，react-window，react-virtualized。react 官方文档里也有介绍性能优化

[gouflv]

你们前端 其实挺适合 vue 的，react 驾驭不来

[pengtikui]

写了个 demo，生成 2000 个 div，每个 div 有一个随机的字符串和背景色，每 100 毫秒随机修改其中一个 div 的字符串和背景色，不知道我的理解是不是正确，效果自己看吧

Demo 地址： https://l7kow2rp5l.codesandbox.io

[zkeeper]

我觉得大家的争论有点偏题了啊. 问题并不在 React 和 Vue 谁好, 或者 React 是不是适合这个场景, 是不是有缺陷.
楼主的需求是: 楼主的公司需要在给定的时间和既定的人力资源(楼主提到的前端工程师)的经验范围内, 有效的解决这个问题.

既然这样, 那就用该前端最熟悉最喜欢的方式去解决掉它, React 再好, 那名前端不熟悉或者不喜欢也是没用的, 也不太可能因为这点事就把前端炒掉或者说评价该工程师水平不行.

这种帖子, 一开始就偏离了主题, 变成了无意义的骂战.

[caiya21]

https://github.com/bvaughn/react-window 了解下 长列表优化不了可以用社区方案

[zhwithsweet]

@chinvo 这个比装的有点大了，一棍子打死了饿了么和滴滴的前端架构了

[zhwithsweet]

@zsx 非常不推荐新人上来就搞 vue，最好是 react 起手，磨练原生 js，ng 进阶学习不同的设计模式，到时候看到 vue 的语法糖们不是手到擒来。说白了就是不能太懒，一直被 yyx 给惯的。什么最佳实践给你想好了，语法糖给你准备一大堆，this 给代理好...配置就完事了。

[deepreader]

@pengtikui 大佬牛逼呀。执行力好强。

[lovelybear]

@zhwithsweet 最好是原生 js，熟悉之后再用 vue

[lizz666]

建议看看尤大在知乎对 vue 和 react 争论做出的回答： https://www.zhihu.com/question/301860721/answer/536290664

[scyuns]

这个时候不是自己用原生写更加好吗？还用什么框架啊！所有的框架都没有原生的效率高。emummmm

[sirnay]

换个前端更容易解决问题。

[designer]

楼主可能是 VUE 高级黑。
VUE 因为多了楼主这类人 变得口碑越来越不好

[Justin13]

@TabGre 官网就是最好的教程，文档，博客都仔细看看。说真的很多人只是看完了 tutorial 就不看了。

[lufengd3]

大家都磨拳擦掌了，楼主还不发 demo ？

[Justin13]

@zkeeper 偏离主题?lz 上来就是一句：
所以，各位认同 React 不适合大数据高频率的论点吗？
一看就是要鄙视 react 的能力了。
被大家教做人以后又含含糊糊的说了一大堆，其实就一个意思:react 上手难，vue 简单。要是一开始就明白说，根本就没事。

[chemzqm]

> 我们发现前端的应用过于卡顿

React 不太适合没有较深前端优化经验的团队，因为它只负责 ui，项目里面数据处理乱七八糟的，它不慢才怪了。

[xdlucky]

我还是觉得这是个算法问题, 话说二叉树的讨论就没了吗? 二叉树行不行楼主试过了吗

[BingoXuan]

@janxin 渲染线程只有一个吧

[scriptB0y]

vue 是怎么解决的呢？

楼主给讲讲 @nohup

[Vegetable]

我讨厌这种信誓旦旦的态度，还 for 循环输出文本卡成狗屎。
觉得自己遇到的问题是没人解决的了的问题。

退一万步说，一千个条目只有一个变化，找出这个的任务为什么要交给 virtualdom ？

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

[TaylorJack123]

看河大讨论技术，胜读十年书。总结一句话，河大牛批

[hronro]

已经辞退。。。这操作也太骚了
只不过这个怕是假的吧

[royzxq]

这操作是真的骚

[keysona]

这个也太 6 了吧

[Pastsong]

因为这个帖子一位前端丢掉了工作。。这讨论的代价。。

[wzhndd2]

性能问题无关框架，任何前端性能问题都可以归结到原生 dom 操作上，前端一定要善于使用 F12 分析性能问题出在哪

[chenqh]

好惨呀

[dremy]

楼主终于为 React 正名了，喜大普奔

[wenzhoou]

刚愎自用。什么叫毕竟项目出问题了得要有个说法。楼主能解释一下吗？

[DOLLOR]

我歪个题，知乎 Web 自从用 React 重构后，性能、体验都比旧版烂得很多。
当然，是不是 React 的错我就不知道了。

[Justin13]

辞退真的秀，研究原型难道是单纯的开发任务么，leader 死哪去了?
如果开发是号称 react 高手，出这种问题确实不该。
但如果是临时学，临时做，出问题那是非常正常的。
出问题了先辞退开发，真是厉害，谁能保证永不出错?
如果有 leader,开发是 react 新手，leader 有主要责任。
如果有 leader,开发号称高手，,leader，开发 55 开。
如果开发的是 leader，号称高手,这种开了确实应该。
如果只有开发，出错就被开，这公司我不敢去。

[meszyouh]

加个 immutablejs 单条数据项抽成组件，在 shouldComponentUpdate 里判断一下，再狠点上个 recycleview 也花不了多少时间吧

[a7217107]

好心疼前端，emmmm。虽然大家都在喷，但是也不希望他丢了工作吧

[gimp]

“就算是换 Vue，辞开发，我 xxx 也...”

...

“ React，真香”

[cnbattle]

抱歉，我笑了 0.0

不能给那位前端一个方向，让其优化吗

公司要说法，不止怪 react 和辞退他这两条路吧

[Shook]

好惨啊，这就被炒鱿鱼了…

[tommyzhang]

如果一定要炒鱿鱼的话 这家公司的技术总监首先应该被辞退吧？

[lepig]

只能说 贵公司的 项目经理也挺垃圾的 我说的是大实话

[sphawkcn]

@hronro #162 哪一楼说了被辞退了？

[zhuoyan]

辞退也太真实了吧

[aaahhh123]

哎 瞎讨论害人家丢了饭碗 现在又是寒冬，真的好吗？

[aaahhh123]

@sphawkcn 看楼主的补充回答

[lovelybear]

其实个人还是比较喜欢 vue 的，React 不太喜欢。

[lideshun123]

直接用 html+js 撸不就没问题了

[pipicat]

@aaahhh123 估计这前端话说的太满了。看楼主补充

[tohert]

上家公司后台程序用 C#写接口，老板说很卡， 要求之后招聘 PY 或者 JAVA 岗位，换成 PY/JAVA

[oyosc]

感觉项目经理也要被辞退

[skyfollow]

虽然被辞退了，希望这个事件对前端有一定的好处吧。
这么多讨论，认真看下来，一个一个的实践验证，也是一次不小的提升。

[reus]

@dawniii vue 也一样的，所有框架都一样的。所有框架最终的目的都是进行一些 dom 操作，怎样使 dom 操作最少，怎样用最小的开销计算出需要进行哪些 dom 操作，框架是用来做这个事情的。更新 800 个元素，那 dom 操作可能就有 800 次，框架还能怎么优化呢？难道 vue 就不需要一个个去更新组件属性？
所以我就说 shouldComponentUpdate 需要根据你的后端数据怎么获取的来实现，如果都是全量数据，那就只能一个个比较，如果是增量数据，你就有办法让它自动化一点。

[exonuclease]

请上 immutable.js 或者手动实现 shouldComponentUpdate 方法

[exonuclease]

而且大量列表渲染不是应该用虚拟化技术么

[kimown]

@DOLLOR

知乎不是各个方面, 一直在走下坡路吗?

[buhi]

vue 唯一的优点就是适合楼主请的前端这种水平不行的菜鸡

[hanangellove]

@Justin13
“辞退真的秀，研究原型难道是单纯的开发任务么，leader 死哪去了?
如果开发是号称 react 高手，出这种问题确实不该。
但如果是临时学，临时做，出问题那是非常正常的。
出问题了先辞退开发，真是厉害，谁能保证永不出错?
如果有 leader,开发是 react 新手，leader 有主要责任。
如果有 leader,开发号称高手，,leader，开发 55 开。
如果开发的是 leader，号称高手,这种开了确实应该。
如果只有开发，出错就被开，这公司我不敢去。”

赞同~

[MuscleOf2016]

服了，这么点事情 就辞退，之前出了生产事故 也没见我们公司辞人，开发的领导尼，都在吃屎吗

[zarte]

应该是说话太满了下不了台了吧。真是个悲惨的故事。

[wangxiaoaer]

楼主，为什么你没被辞退? 这个决定是你跟那个前端同学在项目经理主持的会上讨论决定的啊，难道你跟高层有交易?

[MoRun]

虽然你们的前端确实挺菜的，但是直接辞退怕是有点过分。你们的技术 leader 连前端忽悠你们都分辨不出来，他也有很大的责任

[fanhaipeng0403]

虽然你们的前端确实挺菜的，但是直接辞退怕是有点过分。你们的技术 leader 连前端忽悠你们都分辨不出来，他也有很大的责任

[linxy]

着实厉害，这样就把人开了。假设这位前端不是 leader，开不开人不是 leader 说的算吗？是 leader 会是这个技术实力？
虽然前端态度确实不太好，不好交流，但是最多罚个钱就完了的事，居然把人开了。
看傻了。