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

快 2021 年了, UI 库为什么还要依赖框架?

  •  
  •   gzf6 · 2020-12-04 17:24:10 +08:00 · 8195 次点击
    这是一个创建于 1456 天前的主题,其中的信息可能已经有所发展或是发生改变。

    好多优秀的 UI 库都要依赖框架,即使支持多框架的库,更新进度也不一致,有些甚至相差 1 、2 年,非常可惜。

    但是像 Ionic 那样使用 web component 技术的库,基本上框架无关,代码复用率高,一致性好。但是这类库很少见,是技术上有什么顾虑?还是说纯粹的人手不足?如果公司自建 UI 库使用 web component 的话有哪些暗坑么?

    第 1 条附言  ·  2020-12-04 19:49:11 +08:00
    补充下,是使用环境的依赖,不是开发环境的依赖。比如某个 ui 库,不管用什么技术开发的,只能在某个框架中使用。
    43 条回复    2020-12-07 10:36:23 +08:00
    theprimone
        1
    theprimone  
       2020-12-04 17:32:26 +08:00
    用框架省心啊,总不能用原生 JS 吧,不然不也得自己封装一套像 React 或者 Vue 的 UI 框架去开发业务。
    gzf6
        2
    gzf6  
    OP
       2020-12-04 17:40:17 +08:00
    @theprimone 我看了下,现在这几个框架也可以将组件 build 成 web component,开发方式和写框架组件相差不大。主要是按原来的方式,开发维护一套 UI 库,如果公司未来更换技术栈,那原来的库基本就废了,没人想去迁移的。
    theprimone
        3
    theprimone  
       2020-12-04 17:47:03 +08:00
    就算是使用 web component 也只是提供基础 UI 组件吧,业务组件不还得封装,还有状态管理啥的。考虑另一个极端,如果通过一个 web component 就把整个业务系统渲染了,不还得考虑怎么开发 web component 了吗?
    hst001
        4
    hst001  
       2020-12-04 17:47:19 +08:00
    互联网发展到今天,各种开源产品之间已经连成一种类似产业链的东西了,要是每个 UI 库都从自己生产原材料造螺丝开始做,那结果就是可能没什么 UI 库能用,相反,今天有那么多的开源产品也是因为这条成熟的产业链,所以你的问题问得有点本末倒置了。
    gzf6
        5
    gzf6  
    OP
       2020-12-04 17:53:55 +08:00
    @hst001 不用造螺丝啊,你用框架也能把组件 build 成 web component,熟悉哪个框架就用哪个。我只是觉得好多优秀的库只能在一个框架使用太可惜了。
    crysislinux
        6
    crysislinux  
       2020-12-04 17:55:36 +08:00 via Android
    @gzf6 说是可以 build 成 web component,但是每个都带一套 runtime 你能受得了么。。
    theprimone
        7
    theprimone  
       2020-12-04 17:55:59 +08:00
    微前端不就好了,想咋玩咋玩
    gzf6
        8
    gzf6  
    OP
       2020-12-04 17:57:22 +08:00
    @theprimone 对,功能拆分合理就行,肯定要先写基础组件,复杂的可以用基础组件拼接,当然,UI 库就尽量功能单一,展示布局和数据为主,数据可以从不同框架的业务逻辑里来。
    JerryCha
        9
    JerryCha  
       2020-12-04 18:03:58 +08:00
    然后 UI 学一下 JS,撸起袖子从设计界面到搭界面都自己做了。
    前端工程师:卒
    gzf6
        10
    gzf6  
    OP
       2020-12-04 18:12:50 +08:00 via Android
    @JerryCha 哈哈,这样更好,以后都是 “全干”工程师
    lamada
        11
    lamada  
       2020-12-04 18:21:36 +08:00
    和框架绑定也是效率和生态优先吧,抓个人过来就能干活,没有的网上也容易找到现成的。
    galikeoy
        12
    galikeoy  
       2020-12-04 18:25:29 +08:00
    有部分原因是不兼容 ie(别喷,就算 2021 还是有很多项目要兼容 ie 的)
    SilentDepth
        13
    SilentDepth  
       2020-12-04 18:28:10 +08:00
    [为什么依赖框架?]

    因为 UI 库不是只需要 HTML 和 CSS,它还要有 JS 来实现各种交互。如果 JS 的部分完全不依赖框架就需要自己造很多轮子,这在各种框架大行其道的今天被视为浪费。

    [为什么不用 Web Components ?]

    因为 Web Components 还不成熟啊。
    gzf6
        14
    gzf6  
    OP
       2020-12-04 18:36:49 +08:00 via Android
    @SilentDepth 可以用框架写 web components,不会浪费。成熟就交给时间吧。主要是看了 ionic 那一套感觉技术上可行,我先试试。
    Sivan
        15
    Sivan  
       2020-12-04 18:42:58 +08:00
    wc 组件库已经有很多了,Google 、Saleforce 、SAP 都有自己的。

    而且 stencil 已经一定程度上解决开发成本的问题,wc 组件库需要一些时间。国内的大厂还在推上一轮流行技术栈的相关轮子,相信在 2021 年大家就会产出了。
    wobuhuicode
        16
    wobuhuicode  
       2020-12-04 18:46:46 +08:00
    每个框架使用者有自己的立场。
    从 0 开始? 使用 web Component ? 这些都是每个人自己的立场。
    不能让大家的想法都一致的。
    gzf6
        17
    gzf6  
    OP
       2020-12-04 18:57:01 +08:00 via Android
    @wobuhuicode 嗯,主要是想看看用的人多不多,问问技术上有没有什么坑
    secondwtq
        18
    secondwtq  
       2020-12-04 19:04:22 +08:00
    #2 > 如果公司未来更换技术栈,那原来的库基本就废了,没人想去迁移的

    真的是带快所有前端的带好事,正好重写一个,KPI 就有着落了。
    gzf6
        19
    gzf6  
    OP
       2020-12-04 19:11:22 +08:00
    @secondwtq 哈哈,轮子有一套合适的就行了,还是专注业务
    gzf6
        20
    gzf6  
    OP
       2020-12-04 19:12:48 +08:00
    @galikeoy 对,这是主要问题,得先看看腻子脚本都支持到哪个版本的浏览器
    shyling
        21
    shyling  
       2020-12-04 19:25:17 +08:00 via iPhone
    我觉得这个问题有点像 快 2021 年了,怎么还有那么多优秀的库依赖 java,依赖 c++。。wc 只是还没流行起来,流行起来也会有基于 wc 的不同框架… 另外 ui 库也是框架呀
    gzf6
        22
    gzf6  
    OP
       2020-12-04 19:39:56 +08:00
    @shyling 哦,你可能误解了,我不是说开发上的依赖,是使用上的依赖。开发随便用什么都可以,但是使用时的环境就只能依赖于一个框架就有点可惜。比如你用 java 开发了一个通用程序,结果 build 出的东西只能让它在 Windows 上跑,不会很可惜吗?(大概就这个意思)。至于 ui 的话,我还是觉得只是整体框架的一个表现层而已,尽量和业务层 、服务层、数据层分离,可能对框架的理解不太一样吧。
    love
        23
    love  
       2020-12-04 20:57:57 +08:00   ❤️ 1
    因为纯 JS 非常不适合开发应用,必须要框架。
    要开发框架无关 UI 当然是可以的,比如 Google 官方出品的 Material UI For Web: https://github.com/material-components/material-components-web 然而。。。基本可以算是失败的。因为不用框架组件机制带来的问题太多了(之前 Google 还有一个官方 React 桥接绑定到这个库,后来停更了,为啥用过的人都清楚,我也是用过的,问题太多一言难尽,运行效率也比用纯 React 框架的差太多)
    zy445566
        24
    zy445566  
       2020-12-04 21:14:42 +08:00 via Android   ❤️ 1
    https://github.com/zy445566/before-server
    我这个就是用没有框架依赖 bootstrap 的部分 UI 。然后自己搭的 WebComponents 框架写的
    zy445566
        25
    zy445566  
       2020-12-04 21:19:57 +08:00 via Android
    按我自己的体验来说用 WebComponents 打个框架真的很方便,用不了 100 行。但这 100 行却能为每一次 UV 节约 1MB 以上的流量,真的是值得的。现在很多人觉得框架很难实现,我觉得是被固有观念拖垮了。
    user8341
        26
    user8341  
       2020-12-04 22:36:19 +08:00
    @love
    web component 不是已经写进 w3c 的标准了吗?为什么标准的反而更慢,框架的反而快?
    karott7
        27
    karott7  
       2020-12-04 22:58:27 +08:00 via iPhone
    在推上看到老外发了一句 2020 年了,打包工具还把代码编译成 es5 ……
    Zchary
        28
    Zchary  
       2020-12-04 23:04:00 +08:00
    公司的话可能因为技术累债导致推进慢,这种活可能是吃力不讨好的,没多少人愿意去推行
    loading
        29
    loading  
       2020-12-04 23:15:52 +08:00 via Android
    楼主,你试一下搜 css ui framework 。
    wanguorui123
        30
    wanguorui123  
       2020-12-04 23:35:57 +08:00
    现在前端框架流行的原因主要是:组件的状态管理,UI 组件只是其中的一部分;
    状态管理通俗的讲就是管理页面 /组件之间的通讯与上下文状态,单纯的 WebComponents 没有状态管理这个机制。
    murmur
        31
    murmur  
       2020-12-04 23:37:04 +08:00
    ionic 挺好的,人家现在不限制框架,甚至还接起了维护 cordova 的大旗,就是这个公司有点傲,我们国内小公司想买他的服务都不理我们

    楼主就给人家一顿鄙视
    lxml
        32
    lxml  
       2020-12-05 00:01:29 +08:00
    @karott7 我也想吐槽……尤其是 typescript 默认就是 es5
    love
        33
    love  
       2020-12-05 07:23:38 +08:00 via Android
    @user8341 web components 我没用过不熟,不知道他的状态改变 UI 更新是什么样的,react 是很容易做到状态改变了,只更新必须的部分 dom,而在 react 出现之前,复杂组建状态改变了很难精细的去改变对应的 dom,那样工作量太大了,都是直接全量更新 dom,更新 dom 的成本是很大的
    GrapeCityChina
        34
    GrapeCityChina  
       2020-12-05 09:48:02 +08:00
    这里有一款前端 UI 组件库(商用),不依赖任何框架:WijmoJS ( https://www.grapecity.com.cn/developer/wijmojs )。

    WijmoJS 是一款基于 HTML5 的前端开发工具包,由 80 多种灵活、高效、跨平台、零依赖的 JavaScript UI 组件构成,如表格( Grid )、图表( Chart )、数据分析( Olap )、导航( Navigation )和金融图表等,完美兼容原生 JavaScript,以及 Angular 、React 、Vue 、TypeScript 、Knockout 和 Ionic 等框架,可助力企业以最快的速度开发并构建出一套成熟的 Web 应用程序。

    WijmoJS 自面市以来,已先后在微软 Dynamics 项目、思科、特斯拉、富士通等知名企业中得以成功应用,凭借其先进的体系架构、超过 500 种示例源码、顶级的控件性能、原生触控支持,以及轻松、易用的操作体验,可全面满足企业开发所需,是最适合构建企业级 Web 应用的前端开发工具。
    OHyn
        35
    OHyn  
       2020-12-05 12:08:05 +08:00
    @lxml 哎,老设备让人头痛。
    gzg1023
        36
    gzg1023  
       2020-12-05 15:09:08 +08:00
    懂楼主的意思,element-ui 这种应该是都是机遇自己公司懂产品,就没做跨端吧。
    可以看看这个 https://github.com/primefaces 老哥,把 vue,react,ng 都自己做了一遍
    qwer666df
        37
    qwer666df  
       2020-12-05 15:58:33 +08:00
    @gzg1023 #36 让我想起来了 mingeJs
    phithon
        38
    phithon  
       2020-12-05 16:44:54 +08:00
    可以找有 jquery 版本的 ui 库,我是这样的
    haozes
        39
    haozes  
       2020-12-05 17:18:47 +08:00
    我特么也奇怪,前端不是造轮子快么,WC 的库怎么没蓬勃
    Sapp
        40
    Sapp  
       2020-12-05 18:19:48 +08:00
    @phithon jquery 本身就是依赖了。

    ui 库确实可以不依赖框架,但是这并不是很有意义的事情,ui 库本身不是一个难度特别高的东西,它是一个比较通用的东西,你在 vue 找到的,react 基本也有,如果开发者要不依赖框架,很多东西就要手写 js,这肯定会造成开发成本上升。而目前的 ui 库大多数都是公司内部转化而来的,他当然基于内部的框架优先,在开发速度和适用性做这个平衡。如果是专业的库提供商开发付费版本的,我想可能会支持多框架,但是目前感觉不太行的通。不过 Svelte 这两年逐渐有点发展了,未来可能有基于他做的组件,那就自然是通用了。
    phithon
        41
    phithon  
       2020-12-05 21:47:26 +08:00
    @Sapp 你没用过“有 jquery 版本的 ui 库”。jquery 只作为一些有交互功能的 web component 的交互作用,一般都可以去掉,只保留 css 即可。
    namelosw
        42
    namelosw  
       2020-12-06 11:51:17 +08:00
    大部分框架的核心价值是提供一个类似 reactive var 的功能. 没有这个写稍微复杂点的东西感觉都像吃屎.

    Web component 没有.
    SmiteChow
        43
    SmiteChow  
       2020-12-07 10:36:23 +08:00
    bootstrap/semantic ... UI 都不依赖啊?
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   928 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 21:49 · PVG 05:49 · LAX 13:49 · JFK 16:49
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.