V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Sponsored by
LinkedIn
2000 个不用坐班的远程好工作在召唤你 · 弹性上班不打卡,工作和生活都能拥有
2000 个不用坐班的全球远程工作,帮助 V2EX 的小伙伴开启全新的工作方式。
Promoted by LinkedIn
nohup
V2EX  ›  程序员

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

  •  
  •   nohup · 2018-12-22 14:39:22 +08:00 · 51538 次点击
    这是一个创建于 1373 天前的主题,其中的信息可能已经有所发展或是发生改变。

    因为几个项目下来,我们发现前端的应用过于卡顿,甚至还不如上一版本 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
    我和一位在大厂的朋友沟通联系,他花了一晚上就把项目调优好了,至于辞退也是管理层的意思,我和前端都做不了主。。
    325 条回复    2019-01-04 16:29:01 +08:00
    1  2  3  4  
    geshansuiyue
        1
    geshansuiyue  
       2018-12-22 14:42:42 +08:00   ❤️ 1
    准备看戏
    momocraft
        2
    momocraft  
       2018-12-22 14:44:18 +08:00   ❤️ 3
    能不能把你们实验时的代码发出来看看
    niubee1
        3
    niubee1  
       2018-12-22 14:46:11 +08:00
    编译成 webassembly 试试
    reus
        4
    reus  
       2018-12-22 14:48:25 +08:00   ❤️ 8
    你这前端肯定不懂二分法
    水平不行怪框架?
    hlwjia
        5
    hlwjia  
       2018-12-22 14:50:21 +08:00
    能不能把你们实验时的代码发出来看看 + 1
    reus
        6
    reus  
       2018-12-22 14:50:42 +08:00   ❤️ 15
    当然,就这个需求,vue 确实对菜鸡友好,但请不要说是 react 的缺陷,是你们前端不懂状态管理而已。
    duan602728596
        7
    duan602728596  
       2018-12-22 14:53:05 +08:00 via iPhone   ❤️ 5
    果然是水平不行怪框架
    VDimos
        8
    VDimos  
       2018-12-22 14:57:49 +08:00 via Android
    vue 不也是 vdom 遍历查找更新? react 的快速算法是目前最优的算法,这个框架真不背锅
    shangjiyu
        9
    shangjiyu  
       2018-12-22 14:58:00 +08:00
    flutter ?
    VDimos
        10
    VDimos  
       2018-12-22 14:59:27 +08:00 via Android
    而且大量列表这个还和 css 与 html 有关,有些设置来会很卡
    zuoyouTU
        11
    zuoyouTU  
       2018-12-22 15:00:29 +08:00
    同意 demo 开源下,大家免费帮你找找坑
    codermagefox
        12
    codermagefox  
       2018-12-22 15:01:06 +08:00
    "因为 React 在进行状态更新的时候,会进行判断每一个 listitem 的状态是否有改变。"

    蛤????我学的是假 React?

    Vue 不会这样难道不是因为为了性能手动切断了 Object.defineProperty 的状态更新吗?

    React 的 SetState 做不到??您能把代码发一下吗???

    看我的一头问号
    codermagefox
        13
    codermagefox  
       2018-12-22 15:01:33 +08:00
    @codermagefox #12 看我的->看的我
    reus
        14
    reus  
       2018-12-22 15:03:11 +08:00
    @VDimos 不是,vue 不需要遍历,vue 组件读写属性时会标记为需要更新。react 这个需要自己实现 shouldUpdateComponent 或者用 PureComponent,比 vue 灵活但对菜鸡不友好。
    hlwjia
        15
    hlwjia  
       2018-12-22 15:03:39 +08:00   ❤️ 3
    In conclusion, 前端的门槛太低了
    Cbdy
        16
    Cbdy  
       2018-12-22 15:03:47 +08:00 via Android   ❤️ 1
    技术不行,框架背锅,稳
    leega0
        17
    leega0  
       2018-12-22 15:04:59 +08:00   ❤️ 2
    只想说你们的选择是正确的,react 不是不行,而是不适合你们。
    nohup
        18
    nohup  
    OP
       2018-12-22 15:08:34 +08:00
    这里我的前端回复一下:
    应用用的是 React+Redux+React-Router,demo 就不放了,公司保密

    @codermagefox Vue 有 getter/setter 加持,压根就不需要判断哪些属性变了哪些属性没变。setState 一样要判断属性是否更改,这是很低效反人类的,你需要判断了 1000*N 个属性之后才进行渲染

    @reus 讨论不是更新某个条目去找到这个条目,而是 React 在高频度渲染情况远不如 Vue。React 需要一个个去判断,低效的很呢,作为开发者能参与的性能优化最多加个 PureComponentn,其实没什么软用的,就算你自己写 ShouldComponentUpdate 还是卡成狗屎
    codermagefox
        19
    codermagefox  
       2018-12-22 15:09:00 +08:00
    @reus #14 我甚至怀疑都不到这个优化层级,卡 4-5 秒啊!

    我甚至怀疑原因是他们没有加 Key,不然怎么可能卡 4-5 秒.哪怕有 1/3 走 Update,也就 1000 个条目,会用得着这么久?

    我当初用某开源库就碰到过这种情况,用数据去检索中文 Key 无法检索导致点一下就卡 5 秒.后来还是绕弯路解决的.

    看到这个帖子真是有点生气
    nohup
        20
    nohup  
    OP
       2018-12-22 15:11:37 +08:00
    回复 by 前端

    @codermagefox 我们应用是每秒都会有新数据要刷新,1000 个条目虽说不多,但肯定是有性能问题的,加 key 没什么乱用,react 就是这点比较弱
    codermagefox
        21
    codermagefox  
       2018-12-22 15:14:36 +08:00
    @nohup #20 那么请问一下,不能放源码能不能放源码运行时的 perfermance?这个总不是机密吧?我想看看,如果真是个框架缺陷,我也好好学习一下
    nohup
        22
    nohup  
    OP
       2018-12-22 15:16:59 +08:00
    @codermagefox 什么是运行时 performance ? js 没有这个东西的吧
    codermagefox
        23
    codermagefox  
       2018-12-22 15:17:46 +08:00
    @nohup #22 ChromeDevTool-> Performance
    nohup
        24
    nohup  
    OP
       2018-12-22 15:20:58 +08:00
    @codermagefox 中国人要用中文。好的,我稍后 append 一下
    hlwjia
        25
    hlwjia  
       2018-12-22 15:23:10 +08:00   ❤️ 38
    “中国人要用中文。好的,我稍后 append 一下”

    莫名的喜感
    codermagefox
        26
    codermagefox  
       2018-12-22 15:25:01 +08:00   ❤️ 1
    @nohup #22 而且你们前端总结出来的那个结论,我也觉得是欠妥的.1000*3 的 insert 数量是不可能卡 5 秒的.

    卡 5 秒只有可能是 O(n³)的复杂度,也就是所有 DOM 节点全部走 insert 完全没有走 domdiff

    效果和你们前端做循环的效果是一样的

    循环输出 DOM 的实际复杂度不是 3000,而是对比 10 亿次
    yadgen
        28
    yadgen  
       2018-12-22 15:30:22 +08:00   ❤️ 1
    前端能卡 4-5 秒,你们前端可以换人了。
    项目经理没有主见,估计也是听听你们的意见,感觉似乎是那么一回事儿,就定夺,也可以更换了。
    Kyle18Tang
        29
    Kyle18Tang  
       2018-12-22 15:30:37 +08:00 via Android
    @hlwjia 哈哈哈,我也笑了。而且 chrome 里本来也是英文。。。
    yadgen
        30
    yadgen  
       2018-12-22 15:32:13 +08:00
    追加一点,可以写个 Demo,从没见过有人贴项目代码。
    ugu
        31
    ugu  
       2018-12-22 15:32:48 +08:00
    人不行哦,不赖框架
    yadgen
        32
    yadgen  
       2018-12-22 15:33:10 +08:00
    @hlwjia 我觉得这人跟开发似乎没什么关联,只是个理论伸手党罢了。
    chinvo
        33
    chinvo  
       2018-12-22 15:33:13 +08:00 via iPhone
    典型技术不行怪框架
    坐等下一篇《经过两个月试用我们放弃了 vue 》

    不过说实在的,vue 根本没有生态可言,做项目基本没法用
    zjsxwc
        34
    zjsxwc  
       2018-12-22 15:33:52 +08:00
    还好吧 雅虎金融 用 React 我觉得不卡,没什么性能问题

    https://finance.yahoo.com/most-active?offset=0&count=100
    bb22
        35
    bb22  
       2018-12-22 15:34:16 +08:00
    请到 codesandbox 跑个 demo 让我们看看,不然只能怪你们的前端不行了
    moeone
        36
    moeone  
       2018-12-22 15:34:24 +08:00
    吃瓜
    momocraft
        37
    momocraft  
       2018-12-22 15:37:57 +08:00
    其实我觉得这个数据量 jquery "只" 卡 2s 就有点喜感.

    同为著名框架, 性能差几十倍是不小的新闻了, 发个 demo 也许能上 hn 头条, 你们可以试一下
    chenqh
        38
    chenqh  
       2018-12-22 15:41:09 +08:00
    @zjsxwc 点上一页和下一页为什么会有很长时间的空白,而且一页才 100 个,如果是 1K 的话。。
    chenqh
        39
    chenqh  
       2018-12-22 15:42:12 +08:00
    @momocraft 1K 只卡 2S,够可以了吧
    shyangs
        40
    shyangs  
       2018-12-22 15:42:17 +08:00
    这大新闻为什么不是老外先发现的
    老外不是用 React 更多吗
    ::doge::
    passerbytiny
        41
    passerbytiny  
       2018-12-22 15:43:47 +08:00   ❤️ 2
    大概率:一段时间后,经过技术选型研究,我们放弃了 Vue,转向原生 HTML+Javascript ;再一段时间后,经过技术选型研究,我们放弃了网页端,转向客户端。

    显示 1000 行还要能随机刷新,这基本上属于特殊需求了,通用轮子一般都不能完美解决,要自造轮子。

    你不是前端,直接下了结论,后面又只当前端的传话筒,所以我很想问你一句经典的话:关你屁事?
    chinvo
        42
    chinvo  
       2018-12-22 15:44:42 +08:00 via iPhone
    @chenqh #39 很不可以了(
    chinvo
        43
    chinvo  
       2018-12-22 15:45:43 +08:00 via iPhone
    @chenqh #38 你看网络就明白了(
    lsido
        44
    lsido  
       2018-12-22 15:48:02 +08:00 via iPhone
    前端怎么还没回复,大伙儿等着看戏呢
    reus
        45
    reus  
       2018-12-22 15:51:06 +08:00
    @nohup 问你的前端,去图书馆找书,是不是从头一本本找。1000 个元素,递归拆分成树,有元素更新时,shouldComponentUpdate 只需要执行数次,哪来的一个个判断。所以我一开始就说他不懂二分查找。
    chenqh
        46
    chenqh  
       2018-12-22 15:52:02 +08:00
    @chinvo 看不明白,逃
    creanme
        47
    creanme  
       2018-12-22 15:54:01 +08:00 via Android
    别盲目换框架啊,问题解决不了发群里,或者社区,先咨询一下能否解决再说啊。
    janxin
        48
    janxin  
       2018-12-22 15:56:52 +08:00
    我觉得是 JS 不能多线程导致的渲染效率过低
    nohup
        49
    nohup  
    OP
       2018-12-22 15:56:57 +08:00
    @passerbytiny 的确不关我事,但我要把抛弃 React 的理由拿出来 6 一 6,看看大家的意见
    frozen2013
        50
    frozen2013  
       2018-12-22 15:57:55 +08:00 via Android   ❤️ 5
    我看过一篇介绍 react-fiber 的,里面提到过 fiber 架构出来之前的性能问题,跟你们公司遇到的类似,但是人家做实验 demo 的 dom 个数是 100000 个,10 万个啊!!!
    你们 1000 个就遇到明显卡顿,是不是先花点时间看看如何优化?!突然换框架重写的成本我觉得也是很大的。

    https://www.infoq.cn/article/what-the-new-engine-of-react
    xiaojie668329
        51
    xiaojie668329  
       2018-12-22 15:59:00 +08:00
    这肯定不是 react 的锅。。代码写不好用 vue 同样也会卡。
    nohup
        52
    nohup  
    OP
       2018-12-22 15:59:22 +08:00
    回复 by 前端:

    @reus 现在元素需要更新,但是你就是不知道更新的元素有哪些,所以才一个个用 shouldComponentUpdate 去判断的嘛,这跟元素查找有什么关联吗,难道是我理解错了?
    j717273419
        53
    j717273419  
       2018-12-22 15:59:30 +08:00   ❤️ 1
    你们别这样。。。回头前端要找工作了。。。
    codermagefox
        54
    codermagefox  
       2018-12-22 16:04:42 +08:00
    @nohup #52 不好意思,是我偏激了.你们前端其实这么想是正常的,毕竟我是闲着无聊才经常看源码.

    如果你们真是这种特殊需求,你可以让他去看看 Fiber 架构.这玩意我不懂,但是面试的时候已经被问到了,似乎就是用来解决你们这种特殊需求的.
    reus
        55
    reus  
       2018-12-22 16:08:30 +08:00   ❤️ 1
    @nohup 用二叉树式组件去表示列表,更新一个元素,那就只有那个元素路径上的 shouldComponentUpdate 会执行。说到这个份上都还不理解,那我就没办法了。
    passerbytiny
        56
    passerbytiny  
       2018-12-22 16:08:37 +08:00
    @nohup #44 先下结论再看意见,拿出来的理由是自己不懂的,你这是“看看大家意见”的态度?
    说下你的职位类型吧,你要是项目经理或者管开发进度的,我理解你,只忽略该主题,要不是,就上 block 了。
    scofieldpeng
        57
    scofieldpeng  
       2018-12-22 16:12:49 +08:00
    一般来说都是技术不行,然后又不愿意承认,只好怪框架。坐等楼主上相关不涉及机密的 demo 代码来得出一个严谨的结论
    hlwjia
        58
    hlwjia  
       2018-12-22 16:14:57 +08:00   ❤️ 2
    找了个古老的项目,改了一下录了个视频


    这个是每秒从后端获取 1200 个颜色变化
    beyoung
        59
    beyoung  
       2018-12-22 16:15:12 +08:00   ❤️ 1
    你们真的经过了技术研究? 而不是主观感受
    lihongjie0209
        60
    lihongjie0209  
       2018-12-22 16:15:33 +08:00
    @janxin js 和渲染有什么关系, 渲染是浏览器的工作
    nohup
        61
    nohup  
    OP
       2018-12-22 16:20:57 +08:00
    回复 by 前端

    @reus 我最了解前端了,用几个数据结构的术语就可以说些模模糊糊的话,别人不理解那就是理解能力有问题,而不是自己说话不清不楚
    reus
        62
    reus  
       2018-12-22 16:22:28 +08:00   ❤️ 2
    @nohup 例如更新第 700 个,在各个结点组件的 shouldComponentUpdate 里判断,前 500 个不需要重渲染,后 500 个需要。后 500 个里面,前 250 个需要重渲染,后 250 个不需要。250 个需要重渲染的里面,前 125 个不需要,后 125 个需要。递归下去,到第 700 个,需要调用的 shouldComponentUpdate 次数是 log(2, 1000) * 2,不需要一个个比较。
    hlwjia
        63
    hlwjia  
       2018-12-22 16:23:59 +08:00
    @hlwjia 好吧,vimeo 是被墙的,就这么招吧。能翻墙的就看看吧,看不了没办法啦
    so898
        64
    so898  
       2018-12-22 16:24:49 +08:00
    明天会不会因为 SEO 转回去……
    reus
        65
    reus  
       2018-12-22 16:25:16 +08:00
    @nohup 所以说菜鸡就是菜鸡,懂的人,说到“二分”,就应该领悟了,知道要用二叉树去表示组件,从而高效地判断需要更新哪里。菜鸡呢,说再多也理解不了,反而怪说的人没说清楚。
    251243021
        66
    251243021  
       2018-12-22 16:31:28 +08:00
    纯属写法问题.不怪框架,顶多 vue 更友好而已
    kimown
        67
    kimown  
       2018-12-22 16:33:42 +08:00 via Android
    项目性能考虑,需要换语言,换框架,地球上肯定有案例的,但人能力不行,水平垃圾还做开发,怪语言,怪框架,也是有的,lz 你是上一类人,还是下一类人呢?
    learnshare
        68
    learnshare  
       2018-12-22 16:37:12 +08:00
    这个性能瓶颈并不能怪哪个框架
    是需要自己优化数据量、数据结构或者呈现方式,甚至需要选择一个脑子更好使的产品经理

    只渲染可见部分,就是个不错的优化方式。随手搜到的文章:
    https://zhuanlan.zhihu.com/p/41237949
    https://zhuanlan.zhihu.com/p/26022258
    nohup
        69
    nohup  
    OP
       2018-12-22 16:37:37 +08:00
    回复 by 前端

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

    说的好像只有你会数据结构一样,你当然没有义务完全一步步说的清楚,但是说话歧义这么多,是不是该抽空检查了一下自己?
    hualongbei
        70
    hualongbei  
       2018-12-22 16:38:39 +08:00
    Talk is cheap. Show me the code.
    duzhihao
        71
    duzhihao  
       2018-12-22 16:39:32 +08:00   ❤️ 1
    难道我们开发产品是为了证明 vue 和 react 谁牛逼。别开玩笑了。
    dremy
        72
    dremy  
       2018-12-22 16:49:20 +08:00 via iPhone
    可回收(复用)列表了解一下,1000 多个元素一般不会是一屏全部展示出来的吧,那只 diff 和渲染可以看到的列表元素就好了,几十一百个元素的话肯定不会有问题
    dremy
        73
    dremy  
       2018-12-22 16:51:40 +08:00 via iPhone
    @dremy 和安卓的 recyclerview 或者 iOS 的 UITableView 相同的原理
    sunnyadamm
        74
    sunnyadamm  
       2018-12-22 16:55:13 +08:00 via Android
    围观一下😂😂😂,不做评论
    creanme
        75
    creanme  
       2018-12-22 16:55:16 +08:00
    想看 demo。。。简单演示下就行。
    wu67
        76
    wu67  
       2018-12-22 16:57:57 +08:00   ❤️ 3
    @dremy 还真有那种一页列出一千多两千条的垃圾需求, 产品就是这么要求的...明明告诉过他这要把整个表都列出来了...

    另外上面某人说话戾气真大, 有技术经验确实是可以骄傲的资本, 但不意味这你可以随意鄙视贬低别人, 没几个人是生而知之的, 说的好像别人不能见微知著就是垃圾一样
    Lax
        77
    Lax  
       2018-12-22 17:03:29 +08:00   ❤️ 1
    一个项目用 vue,有一个列表,10000 条数据的列表,首次打开和更新会都感觉卡顿(排序+渲染接近 1s ),减少到 5000 条数据时感觉卡顿不明显。
    用浏览器 profiling 工具看到大部分时间在遍历 dom 的操作。
    这类问题解决方法是只把需要展示出来的添加到页面。我用了这个库: https://github.com/Akryum/vue-virtual-scroller
    换成 vue 之后你们 1000 条数据时的问题,可能会延缓到 5000 条以后才遇到,也算解决了问题。但是我并不认为 react 会“不行”,可能不适合你们使用。
    murmur
        78
    murmur  
       2018-12-22 17:06:15 +08:00
    @Lax vdom 的框架 batch insert 都要趴窝
    还得 jquery+template 一次生成字符串一次插入搞定
    reus
        79
    reus  
       2018-12-22 17:07:12 +08:00
    @nohup 那你们前端知道用 react 怎么实现了没?
    will0404
        80
    will0404  
       2018-12-22 17:13:00 +08:00   ❤️ 2
    你的 listitem 组件可能很复杂,也可能很简单,1000 个可以说多,也可以说非常少。
    无论如何,一秒钟改变其中一个的状态,基本上不会造成性能问题,别说 4s,1s 都不可接受。
    我刚刚试了一下每一秒改变 10000 个组件的状态,React 每次重新渲染都少于 400ms。当然我实验的组件很简单,它没有子组件。
    我给你提供个思路,ReactDevTool 可以看到每次操作哪些组件被重新渲染了,显然,你有太多组件重新渲染了,实际上每次只需要重新渲染一个。一般情况下,用 shouldComponentUpdate 就可以解决。但我不知道你的情况有多复杂,就不多做评论了。
    不过我看了下上面的回复,不觉得这是 React 的问题。
    lufangfan
        81
    lufangfan  
       2018-12-22 17:18:44 +08:00
    我是来学习的,希望会有大神能在这个话题下讲解。
    bookit
        82
    bookit  
       2018-12-22 17:19:48 +08:00
    不判断了,直接 1000 个全部更新要多长时间?

    我觉得也不需要 5 秒。。。
    ByZHkc3
        83
    ByZHkc3  
       2018-12-22 17:20:53 +08:00 via Android
    大厂不用 react ????????????????
    xuhaoyangx
        84
    xuhaoyangx  
       2018-12-22 17:23:46 +08:00
    我只按照移动端 Native 的方式来说.....这种列表,item 不是需要展示或快要展示时,才依次渲染么???? ,你让原生一下子全部渲染,并动态更改信息且每次都要全部渲染出来,也会卡啊。
    wjl4107336
        85
    wjl4107336  
       2018-12-22 17:35:00 +08:00 via Android
    引战
    Weny
        86
    Weny  
       2018-12-22 17:35:48 +08:00
    水平太差,简单点一个 shouldComponentUpdate 解决 ,稍微稳妥一些上 immutable.js immer.js 。这个水平,怕是拉个高中生都写得比你们强吧。15 年的时候 react states 就有 immutable.js 做为解决方案了。几个国内大厂都有实践过,特别是在移动端。
    reus
        87
    reus  
       2018-12-22 17:43:22 +08:00   ❤️ 2
    @wu67 既然引战就做好被喷的准备再来,受不了贬低就不要引战
    React
        88
    React  
       2018-12-22 17:56:30 +08:00   ❤️ 5
    https://github.com/jonmiles/react-performance-tests
    这个是 15 年的测试,渲染 10000 个小方块,哪有你说的那么不堪
    Arrowing
        89
    Arrowing  
       2018-12-22 18:01:31 +08:00 via Android   ❤️ 1
    看到描述就知道楼主要挨喷了,果不其然,保重啊楼主。
    Justin13
        90
    Justin13  
       2018-12-22 18:11:41 +08:00 via Android
    我大胆的猜测下,你们的每次更新都会改变所有节点的数据的引用。或者改变了某些下传的衍生数据的引用。
    这都会导致每次都要更新整个组件树。
    真正耗时间的一定是你们的 code 而不是 react 的 code。
    shuhao
        91
    shuhao  
       2018-12-22 18:17:31 +08:00 via Android
    围观
    Justin13
        92
    Justin13  
       2018-12-22 18:19:59 +08:00 via Android
    React 走的是函数式的路子,如果说写 React 的过程中需要通过深比较来控制刷新,只能说明你是在逆着 React 的范式在写,根本没有完全理解其思想。
    基于同样的理由,我也反对 reselect 这个库。它虽然解决的痛点,但是光治标不治本。用了反而鼓励你继续乱搞。
    jason94
        93
    jason94  
       2018-12-22 18:22:52 +08:00
    吃瓜群众,前来围观
    br00k
        94
    br00k  
       2018-12-22 19:42:55 +08:00 via iPhone
    这样很难帮到你。整个 demo 出来找问题就简单了。
    rrfeng
        95
    rrfeng  
       2018-12-22 20:31:10 +08:00 via Android
    知乎上有个争论性问题上,有个回答说专门做高度复杂的 ERP 系统的,react 用的很好。

    1 确实是水平不行怪框架
    2 水平不行也不是什么错,选择合适的才对
    3 angular 一样也可以选择啊
    Biwood
        96
    Biwood  
       2018-12-22 20:38:52 +08:00
    楼主如果把问题的核心代码写个 demo 发到这儿来一起讨论一下就好了,标题和正文确实非常容易不必要的引起口水之争,看不到具体的代码实现,怎么吵都没有意义
    leo8
        97
    leo8  
       2018-12-22 20:41:54 +08:00 via iPhone
    想看下到底是什么原因造成的🧐
    chen26
        98
    chen26  
       2018-12-22 20:53:35 +08:00
    围观
    creanme
        99
    creanme  
       2018-12-22 21:20:57 +08:00
    你要不看看这个

    https://www.zhihu.com/question/301860721/answer/541184853
    平均 10000 条,在前端约进行 10 万次匹配
    abcbuzhiming
        100
    abcbuzhiming  
       2018-12-22 21:31:46 +08:00
    前端三大 MVVM 框架论原理都是半斤八两的,我不认为他们的性能会有数量级的差别,所以我认为你们的前端压根就没抓住问题根本,所以你们用 Vue 多半还是会撞上这个南墙
    1  2  3  4  
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2484 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 61ms · UTC 11:28 · PVG 19:28 · LAX 04:28 · JFK 07:28
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.