快 2021 年了， UI 库为什么还要依赖框架？

[gzf6]

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

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

[theprimone]

用框架省心啊，总不能用原生 JS 吧，不然不也得自己封装一套像 React 或者 Vue 的 UI 框架去开发业务。

[gzf6]

@theprimone 我看了下，现在这几个框架也可以将组件 build 成 web component，开发方式和写框架组件相差不大。主要是按原来的方式，开发维护一套 UI 库，如果公司未来更换技术栈，那原来的库基本就废了，没人想去迁移的。

[theprimone]

就算是使用 web component 也只是提供基础 UI 组件吧，业务组件不还得封装，还有状态管理啥的。考虑另一个极端，如果通过一个 web component 就把整个业务系统渲染了，不还得考虑怎么开发 web component 了吗？

[hst001]

互联网发展到今天，各种开源产品之间已经连成一种类似产业链的东西了，要是每个 UI 库都从自己生产原材料造螺丝开始做，那结果就是可能没什么 UI 库能用，相反，今天有那么多的开源产品也是因为这条成熟的产业链，所以你的问题问得有点本末倒置了。

[gzf6]

@hst001 不用造螺丝啊，你用框架也能把组件 build 成 web component，熟悉哪个框架就用哪个。我只是觉得好多优秀的库只能在一个框架使用太可惜了。

[crysislinux]

@gzf6 说是可以 build 成 web component，但是每个都带一套 runtime 你能受得了么。。

[theprimone]

微前端不就好了，想咋玩咋玩

[gzf6]

@theprimone 对，功能拆分合理就行，肯定要先写基础组件，复杂的可以用基础组件拼接，当然，UI 库就尽量功能单一，展示布局和数据为主，数据可以从不同框架的业务逻辑里来。

[JerryCha]

然后 UI 学一下 JS，撸起袖子从设计界面到搭界面都自己做了。
前端工程师：卒

[gzf6]

@JerryCha 哈哈，这样更好，以后都是 “全干”工程师

[lamada]

和框架绑定也是效率和生态优先吧，抓个人过来就能干活，没有的网上也容易找到现成的。

[galikeoy]

有部分原因是不兼容 ie(别喷，就算 2021 还是有很多项目要兼容 ie 的)

[SilentDepth]

[为什么依赖框架？]

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

[为什么不用 Web Components ？]

因为 Web Components 还不成熟啊。

[gzf6]

@SilentDepth 可以用框架写 web components，不会浪费。成熟就交给时间吧。主要是看了 ionic 那一套感觉技术上可行，我先试试。

[Sivan]

wc 组件库已经有很多了，Google 、Saleforce 、SAP 都有自己的。

而且 stencil 已经一定程度上解决开发成本的问题，wc 组件库需要一些时间。国内的大厂还在推上一轮流行技术栈的相关轮子，相信在 2021 年大家就会产出了。

[wobuhuicode]

每个框架使用者有自己的立场。
从 0 开始？ 使用 web Component ? 这些都是每个人自己的立场。
不能让大家的想法都一致的。

[gzf6]

@wobuhuicode 嗯，主要是想看看用的人多不多，问问技术上有没有什么坑

[secondwtq]

#2 > 如果公司未来更换技术栈，那原来的库基本就废了，没人想去迁移的

真的是带快所有前端的带好事，正好重写一个，KPI 就有着落了。

[gzf6]

@secondwtq 哈哈，轮子有一套合适的就行了，还是专注业务

[gzf6]

@galikeoy 对，这是主要问题，得先看看腻子脚本都支持到哪个版本的浏览器