首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  程序员

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

  •  
  •   nohup · 242 天前 · 38403 次点击
    这是一个创建于 242 天前的主题,其中的信息可能已经有所发展或是发生改变。

    因为几个项目下来,我们发现前端的应用过于卡顿,甚至还不如上一版本 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 条附言  ·  241 天前
    各位,这不是“水平不行怪框架”,这是取舍的问题。
    假如项目时间给够,钱给够,你让我用 JQuery 去开发,渲染细节细腻到每个 DOM 层面,那都是没问题的,而且我也不用去看什么源码,什么最佳实践 。
    如果 React 解决问题不那么直接,直接上手还有这么多坑,难道锅全是开发人员背吗?你要追求开发体验,语法优雅,项目重构方便,而对于用户来说界面响应、访问速度才是主要的,其他都是瞎扯
    第 2 条附言  ·  240 天前
    我们已经辞退那位前端同学了,他也表示理解,毕竟项目出问题了总要有个说法,看有 V 友提供的 demo 都很流畅,看来还是人的问题是主要的。
    抱歉给 React 抹黑了,其实 React 应该还是很 NB 的
    第 3 条附言  ·  240 天前
    我和一位在大厂的朋友沟通联系,他花了一晚上就把项目调优好了,至于辞退也是管理层的意思,我和前端都做不了主。。
    325 回复  |  直到 2019-01-04 16:29:01 +08:00
    1  2  3  4  
        301
    ala2008   239 天前
    我们公司 vue 和 react 并行。。
        302
    Hconk   239 天前 via Android
    娱乐圈又添新秀
        303
    sunboy911   239 天前
    楼主不怀好意
        304
    xuhp   239 天前   ♥ 8
    “经过技术选型研究,我们放弃了 那位前端同学”
        305
    bk201   239 天前
    所以技术人员不要太关注技术,稍微关注下空气。
        306
    cheesemp   239 天前
    首先站在这个问题是真实的情况下:

    各位同行, 别当嘴强王者了. 大家都是混口饭吃, 搞的人家被开了, 何必呢?

    一句话. 找的是前端工程师还是前端科学家?

    工程师的目的不就解决问题吗? 站在同行的角度, 以自己最优的选择出发是最正确的, 那怕他用 JQ, 他能搞定那就没问题.其它的都不重要. 何况人家用 react 也实现出来了. 这起码就够格了(你第一版就完美了?)

    用 VUE 就政治不正确了? 那做 Z F 工程的兼容 IE 不是要送去停车场了?
    只会嘴上 BB, 需求方嘴上说的好听. 表面上的都是 冰山一角.

    想换的托词一堆. 别人也不想听. 能解决问题就行. 假如这位老哥. 换完 VUE 还是搞不定. 那就另当别论.
        307
    jimrok   239 天前
    放心,过了这坑,还有别的地方能绊倒你们的前端。
        308
    kingcc   239 天前
    楼主真是厚黑学专家啊…太可怕了
        309
    Geniusssssss   238 天前
    前端问题不是很多 楼主你嘛 适合当管理层 别当程序员了
        310
    a4854857   238 天前
    卧槽。我就说这个帖子好几天了有什么好吵了。实在是忍不住有点进来看了一眼。。。这剧情实在是。。。
        311
    geekjc   238 天前
    @lidongyx 缺少你这种大佬入驻本平台写文章啊,增加点优秀技术文章,刚兴趣可以写写啊
        312
    shiye515   238 天前 via iPhone
    拉不出屎赖地球引力不够
        313
    tatelucky   238 天前
    坐观 react vs vue 我预测 react 赢 来自后端的观察
        314
    s609926202   238 天前
    贵司不会就一个前端吧,,人非圣贤孰能无过!
        315
    s609926202   238 天前
    还有,被辞退了,还表示理解......可能前端同学早就不想干了、、
        316
    lzszone   238 天前
    就事论事的说...
    1000 条不多呀...
    不至于到优化的层面吧..
        317
    frozen2013   238 天前 via Android
    本来可以纯粹是技术讨论,被题主搅成办公室政治,还 TM 放在网上嘚瑟。
    后悔回你的帖。。。
        318
    RRRSSS   238 天前
    Angular??
        319
    lingyi95   237 天前
    @codermagefox 我想不通,我刚写了个 demo,一万个色块,同时随机变色,也不卡 5 秒啊,react16
        320
    lingyi95   237 天前
    我觉得什么优化都不做也不会卡 5 秒
        321
    javascr1pt   237 天前
    心疼,真的心疼
        322
    joinmouse   234 天前
    难道作为一个前端不是应该想想在 react 的框架上学会去怎么优化嘛
        323
    momocraft   234 天前
    @cheesemp 遇到个不被 (还没被) 自己连累的框架未必能叫"解决问题"

    写不出东西也不要推给 "我是工程师不是科学家", 不知道的以为是让人造火箭呢

    正经分析过性能不给框架抹黑的人愿意和这样的共称工程师吗?
        324
    n313893254   234 天前
    看了这个帖子,以后不敢在同事面前 diss Ember.js 了 [捂脸
        325
    Xek1n   228 天前
    大厂的朋友这么 nb 嘛…花了一晚上就全调优 ok 了?
    1  2  3  4  
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   3839 人在线   最高记录 5043   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 22ms · UTC 07:47 · PVG 15:47 · LAX 00:47 · JFK 03:47
    ♥ Do have faith in what you're doing.