经过技术选型研究，我们放弃了 React，转向 Vue

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 2170 天前的主题，其中的信息可能已经有所发展或是发生改变。

因为几个项目下来，我们发现前端的应用过于卡顿，甚至还不如上一版本 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 不适合大数据高频率的论点吗？

第 1 条附言 · 2018-12-22 15:55:49 +08:00

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

第 2 条附言 · 2018-12-23 23:37:45 +08:00

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

第 3 条附言 · 2018-12-24 09:15:09 +08:00

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

React

Vue

条目

前端

325 条回复 • 2019-01-04 16:29:01 +08:00

1 2 3 4

❮

❯

201

Lisk

2018-12-24 10:52:45 +08:00

不得不说楼主隐藏的很深，其实你早就看那个前端不顺眼了
先开一个嘲讽贴说 react 不如 vue，然后如期收到回复
再把这个贴子给那个前端看，间接打他的脸
获得了证据后马上通知管理层，让前端背锅
最后再找一个大厂的人盖棺定论，666

202

az1996

2018-12-24 10:57:57 +08:00

react-virtualized 了解一下？

203

mrcode

2018-12-24 10:59:25 +08:00

这帖子一开始就是抱着黑公司的心态去的吧😂

204

l00t

2018-12-24 10:59:38 +08:00

@Lisk #201 城市套路深啊

205

mrcode

2018-12-24 10:59:51 +08:00

@Lisk 不能同意更多

206

golanger1

2018-12-24 11:00:11 +08:00

贴个 react-virtualized 链接 https://github.com/bvaughn/react-virtualized

207

Asice

2018-12-24 11:01:49 +08:00

没完全了解源码的人敢说的这么绝对就不是个合格的程序员

208

HENQIGUAI

2018-12-24 11:05:37 +08:00

围观吵架，好过瘾，学到了，感谢各位。

209

anmie

2018-12-24 11:05:54 +08:00

这波操作真的秀，楼主有点人性就把公司名暴露出来，我们好拉黑

210

v2chou

2018-12-24 11:12:48 +08:00

翻译一下：前端不是我开的是管理层开的和我没有关系

211

DXpro

2018-12-24 11:14:44 +08:00

牛逼牛逼，前端从讨论到被辞退见识了...

212

lucahan

2018-12-24 11:16:55 +08:00

@Lisk 十分赞同。刚开始看这个帖子的时候，我还以为楼主是带 vue 和 react 的节奏，没想到最后居然搞得让前端离职了。只能说楼主这种人很可怕了。

213

keysona

2018-12-24 11:19:28 +08:00

可怕

214

ucanuup

2018-12-24 11:27:49 +08:00

@Lisk 同意，但就事论事，前端这么菜，被炒是应该的。

215

tianyou666shen

2018-12-24 11:29:30 +08:00

一般人处理问题都是最轻松的方式
找个朋友问问难道比大会上决定换框架重构还难吗
非得要闹到高层介入开除人然后才想到朋友?
所以楼主为什么这么干?
为什么最后论坛框架撕了前端人走了大家贡献方案了你最后收功劳了
这也太优(厚)秀(黑)了吧

216

beginor

2018-12-24 11:32:02 +08:00 via Android

这算不算是杀了一个程序员祭呢？ 🦍

217

Jimrussell

2018-12-24 11:32:43 +08:00

这个时候怎么不说菜是原罪了？楼主这波秀到头晕的操作，我倒是觉得没什么问题。

楼主那个 ex 前端同事，估计就是又菜脾气又大然后比较喜欢甩锅的那种。同为打工阶层，我反正也是受不了这种前端作为同事的。

218

TomVista

2018-12-24 11:35:17 +08:00

现在开始讨伐楼主了,楼主你说,你让我们说什么好呢?

219

leinov

2018-12-24 11:39:10 +08:00

好怕怕

220

VoidChen

2018-12-24 11:40:34 +08:00

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

221

robinlovemaggie

2018-12-24 11:54:33 +08:00

来自某推的#前端娱乐圈

222

sSsSsSs

2018-12-24 11:58:24 +08:00

@Jimrussell
觉得楼主没问题 +1

223

andyL

2018-12-24 12:10:03 +08:00

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

224

aniua

2018-12-24 12:13:23 +08:00

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

225

lsvih

2018-12-24 12:15:23 +08:00

太秀了，这能把人开了

226

ben1024

2018-12-24 12:45:59 +08:00

开人的操作令人窒息

227

IWSR

2018-12-24 13:02:59 +08:00

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

228

wly19960911

2018-12-24 13:06:31 +08:00

@robinlovemaggie #220

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

229

SEARCHINGFREE

2018-12-24 13:08:20 +08:00 via iPhone

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

230

isbase

2018-12-24 13:19:31 +08:00 via Android

用 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

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

231

bxj

2018-12-24 14:07:30 +08:00

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

232

yuxuan

2018-12-24 14:17:54 +08:00

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

233

miv

2018-12-24 14:45:24 +08:00

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

234

codermagefox

2018-12-24 15:05:42 +08:00

看了新 append,突然好内疚

235

rabbbit

2018-12-24 15:14:05 +08:00

厚黑学的完美实践

236

leoShen

2018-12-24 15:14:12 +08:00

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

237

erooo

2018-12-24 15:15:13 +08:00

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

238

oqpqw

2018-12-24 15:16:27 +08:00

HDNB

239

ashCloud

2018-12-24 15:18:30 +08:00

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

240

gimp

2018-12-24 15:19:29 +08:00

剧情反转，有点意思

241

icop

2018-12-24 15:24:08 +08:00

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

说明你们技术 leader 也不行。

242

icop

2018-12-24 15:28:57 +08:00

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

243

66beta

2018-12-24 15:29:43 +08:00 via Android

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

244

crystal1992

2018-12-24 15:35:10 +08:00

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

245

Raisu

2018-12-24 15:36:29 +08:00

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

246

lwlipuyang

2018-12-24 15:51:51 +08:00

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

247

a714714a2008

2018-12-24 15:54:17 +08:00

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

248

jon

2018-12-24 16:13:10 +08:00

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

249

bofei

2018-12-24 16:24:32 +08:00

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

250

dd0754

2018-12-24 16:29:22 +08:00 via iPhone

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

251

IBN5100

2018-12-24 16:40:32 +08:00

NB。。

252

Rhonin

2018-12-24 17:18:23 +08:00

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

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

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

253

2018-12-24 17:21:03 +08:00

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

254

Sevenskey

2018-12-24 17:48:42 +08:00

太秀了。。学习了

255

jiji262

2018-12-24 18:30:37 +08:00 via iPhone

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

256

wuhongwei

2018-12-24 18:39:27 +08:00

@fy 秀儿！是你吗？

257

wangxiaoaer

2018-12-24 18:48:29 +08:00

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

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

258

houyujiangjun

2018-12-24 19:00:02 +08:00

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

259

yiqidaoshan

2018-12-24 19:03:55 +08:00

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

260

masahiro

2018-12-24 19:15:45 +08:00

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

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

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

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

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

261

TimPeake

2018-12-24 19:17:43 +08:00

@robinlovemaggie 有链接吗？

262

kingcc

2018-12-24 19:19:30 +08:00 via Android

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

263

wrq

2018-12-24 19:20:27 +08:00 via iPhone

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

264

ArianX

2018-12-24 19:25:37 +08:00 via Android

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

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

265

vicvinc

2018-12-24 19:26:53 +08:00

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

266

Huelse

2018-12-24 19:33:31 +08:00

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

267

marksaas

2018-12-24 19:48:05 +08:00

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

268

publicvoid

2018-12-24 20:17:38 +08:00

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

269

jerrry

2018-12-24 20:27:12 +08:00 via Android

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

270

marksaas

2018-12-24 20:44:55 +08:00

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

271

xiaoxiuaoliang

2018-12-24 21:41:37 +08:00 via Android

令人感到窒息的操作

272

ljcarsenal

2018-12-24 21:43:42 +08:00 via Android

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

273

jerrry

2018-12-24 22:05:01 +08:00 via Android

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

274

hlwjia

2018-12-24 22:11:37 +08:00 via iPhone

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

275

marksaas

2018-12-24 22:14:40 +08:00

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

276

marksaas

2018-12-24 22:17:34 +08:00

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

277

visonme

2018-12-24 22:30:58 +08:00

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

278

inpm

2018-12-24 22:47:18 +08:00

是个狼人

279

nikolai

2018-12-24 23:26:18 +08:00

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

280

geekjc

2018-12-24 23:50:55 +08:00

是时候推荐一波我用 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)

281

gouflv

2018-12-25 02:45:57 +08:00 via Android

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

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

282

lidongyx

2018-12-25 03:42:54 +08:00 via iPhone

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

283

lidongyx

2018-12-25 04:01:47 +08:00 via iPhone

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

284

marksaas

2018-12-25 08:20:18 +08:00

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