经过技术选型研究，我们放弃了 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 的

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

[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]

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

[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]

剧情反转，有点意思

[icop]

我打断一下，什么列表条目有 1000 行。
我算你一行 10px 高度好了。手机 2000px。也就是说手机屏幕 5 页。
框架实在解决不了，那你把当前显示数据分为五层 [缓存层、预处理前层、显示层、预处理后层、缓存层] 。

说明你们技术 leader 也不行。

[icop]

补一句，怕你看不懂。缓存层的数据不给用户显示的。预处理层、显示层数据给用户显示。也就是用户显示的数据只有 3 页。2 页不能看， 一页当前正在看。滑动时候，预处理层做数据的移除或者增加。

[66beta]

结论不是楼主一起得出的么？楼主全身而退了？

[crystal1992]

菜鸟表示看的受益匪浅，
不过大家好像从头到尾都忽略了一个事，这个前端在这公司是个什么级别，薪资什么水平
我觉得薪资和能力应该是挂钩的。
如果是一个拿着几 k 的新人，被一群几十上百 k 的大佬集火，是不是有点不公平。
最后，你们真垃圾，这前端是不会注册账号吗还要你来当传话筒，心思太阴险了，我感觉楼主从发帖开始就是在等着看前端笑话的。

[Raisu]

我感觉你用 react 做不了的，用 Vue 应该也实现不了

[lwlipuyang]

你们这个团队还能呆的下去？

[a714714a2008]

跟着各位大佬学习撕逼技术

[jon]

果然功劳都是领导的黑锅都是员工的

[bofei]

首先，楼主一直在说 我和前端， 所以楼主不是前端
第二，楼主说“在项目经理的会议主持下”，所以楼主不是项目经理
那楼主是什么呢 大家猜一猜

[dd0754]

不给前端机会看能不能优化直接开了这操作 666

[IBN5100]

NB。。

[Rhonin]

@chinvo
> 典型技术不行怪框架
坐等下一篇《经过两个月试用我们放弃了 vue 》

不过说实在的，vue 根本没有生态可言，做项目基本没法用

你第一句话已经回复了第三句话 [斜眼笑]

[fy]

经过技术选型研究，我们开除了前端

[Sevenskey]

太秀了。。学习了

[jiji262]

去看看 tw 的 tech radar 吧 看看上面 r 和 v 的阶段

[wuhongwei]

@fy 秀儿！ 是你吗？

[wangxiaoaer]

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

是不是让人家自愿离职的，连补偿都没有啊？

[houyujiangjun]

嗯，辞退了，你为什么不引咎辞职呢？

[yiqidaoshan]

槽点太多，都不知从哪吐。。

[masahiro]

一派胡言， [React 不适合大数据高频率] 的论点绝对的错误
我猜你的程序运行在 react 16 低版本吧……

只想说，你以为 react fiber 是没用的吗？

有两点，会保证 react 进行大量数据渲染，不会卡顿

1. keyed 给每个子选项加 key，那它进行 diff patch 的时候就会重复利用某些可以重复利用的孩子
2. fiber，时间切片会使得你在进行大量数据操作的时候，每一帧塞满后就将 yield 交给浏览器，然后作废继续下一帧，再塞满一帧，重复这个过程，看似你在渲染很大量的数据，却已经切片了

所以说这个论点是完全错的——
要说现在有个框架能大量数据还不卡，那一定是 react，vue 的时间切片还得等 3 呢

[TimPeake]

@robinlovemaggie 有链接吗？

[kingcc]

笑死我了。楼主，我虽然不同意你家前端的话，但是我站你家前端的边

[wrq]

卧槽这也太秀了 8 几天前还以为是前端日常撕逼 今天一看竟然是借刀杀人……

[ArianX]

“的确不关我事，但我要把抛弃 React 的理由拿出来 6 一 6,看看大家的意见”

楼主刚甩下这种语气的话，前端就被辞退了，而且感觉对此一点愧意也没有。真的不是看不惯前端故意开个帖子拉嘲讽？

[vicvinc]

这真的。。 不分析一下内存占用，js 调用栈上来就直接喷框架，还好没怀疑是电脑的问题，不然就能给前端配个 MAC 了

[Huelse]

@Lisk 虽然你说的很有道理，但我还是在这里奉劝各位理智点，你这样说的话也是有阴谋论嫌疑的。当然，这只是我的看法。

[marksaas]

看了这么多回复，没有人提出 erp 项目选的架构有问题？这种系统还是服务端渲染是王道。。

[publicvoid]

这怎么看都不符合平常的操作，首先，出问题了是程序员查找问题，程序员找不到找技术管理，管理搞不定再找行业大牛，后面依据事故大小，该扣钱的扣钱，该降级的降级。然而，楼主公司先讨论一波，然后发帖被打脸，然后求大厂朋友优化，然后开前端。。。

[jerrry]

@marksaas 这种系统服务器渲染有什么优势吗

[marksaas]

@jerrry 好处太多，服务端渲染每次渲染好 dom，填充好数据，大大降低了系统响应时间，这其实就是传统的 mvc 架构。
以 java 为例，选用 jsp+java （复杂系统一般会用 rpc 框架再分一层做分布式系统）放在一个 servlet 容器。react 也支持服务器渲染，架构复杂点，要引入 nodejs，内网访问后端（ http,rpc...），并缓存部分数据。

[xiaoxiuaoliang]

令人感到窒息的操作

[ljcarsenal]

坐等我就是那个被开除的前端

[jerrry]

@marksaas 我之前觉得 ERP 这种对 SEO 没要求，基本为内网使用的项目还是放在前端更合适，不占用服务器性能，开发效率高

[hlwjia]

@marksaas 问一下，传统 MVC 架构是不是每点一次，页面都需要刷新一次？

[marksaas]

@hlwjia 恩，可以控制局部刷新。

[marksaas]

@jerrry seo 可以不考虑，erp 一般都是企业内网使用，设计的内容比较敏感，前后端不分离会好些。

[visonme]

结局弯转的有点大 ╮(╯▽╰)╭

[inpm]

是个狼人

[nikolai]

爆公司名吧，好让大家避坑

[geekjc]

是时候推荐一波我用 nodejs 开发的学习平台了，
1. [DOM 探索之基础详解篇]( https://www.geekjc.com/ebook/description/5bb9b9f3e132926e1b268ec0/init)
2. [React 模式]( https://www.geekjc.com/ebook/detail/5bae0c10ddb4f437ecfdc708/init)
3. [前端常见面试题汇总]( https://www.geekjc.com/ebook/detail/5ba5bcae7143880b09cb4d54/init)

[gouflv]

楼主你这破技术，以后就别讨论前端了。


另外，从发帖的动机来看，楼主不是坏就是傻

[lidongyx]

@geekjc 你丫的，这时候发链接我还以为你是个王者，打开小程序一看文章内容...

[lidongyx]

@marksaas 好像没有看到更加具体的项目需求，我好奇的是什么情况会需要“每个 tab 显示 1000 个列表条目”，难道是数据可视化项目？不然这要求特别没有道理。抛开具体需求谈解决方案不大合适。

[marksaas]

@lidongyx 我看到具体需求了，大家多少人都在讨论这个，很多人都给出 react 解决方案，我只是从另外一个角度来说。没有结合 erp 系统总体来讨论，erp 一般是企业内部人员，几个到几十人用，操作页面不是很频繁，页面比较复杂，显示 1000 条的需求可能有，每次查数据库返回也不是啥大的性能问题，所以引出服务端渲染这个话题。

[lihongjie0209]

@marksaas 动态刷新的怎么服务器端渲染?

[947211232]

真的很秀啊，忍不住来张合影呢。

[zanjs]

驾驭不了 就不要职责，那是你的取点

[lepig]

什么 PO BI 公司。 你们放弃就放弃呗 还跑来发个公告说你们放弃 React

管理层 也是一帮智障

[SakuraKuma]

这，弯道翻车。。。
随意 google 下都不是这个结果，默哀一哈。。

[alamaya]

这···人干事？

[ookkxw]

@nohup 我只想知道哪个公司，好让我拉黑

[marksaas]

@lihongjie0209 我没有针对这个具体的问题来讨论，没有用过 react 实现服务端渲染，或许可以渲染部分组件，需要动态刷新得地方在客户端渲染。

[huijiewei]

楼主也是惨

在公司被前端怼的没办法了

结果来这里发贴没几天，估计会被怼到删号吧

可怕的某圈

[J2s]

现在学 react 会被辞退么？

[xiaoxinshiwo]

@j717273419 #53 这层神预言

[luvxy]

@lwlipuyang 这种氛围怎么干活。。。。

[Heanes]

优秀。。

[molvqingtai]

出问题扣钱可以，辞退有点过了

[sunzhenyucn]

太特么秀了，现在搞前端太危险了。

[amhere]

哈哈哈，楼主是个干大事的人