web

今天这个 Antd 咱们是非换不可吗？

最近在思考一个可有可无的问题：

“我们是不是要换一个组件库？”

为什么会有这个问题？

简单同步一下背景，我效力于 Lazada 商家前端团队。从接手系统以来(近 2 年) 就一直使用着 Alibaba Fusion 这套组件库。据我所知淘系都是在使用这套组件库进行业务开发，已经有 7 ~ 10 年了吧。我们团队花了 2 年时间从 @alife/next(内部版本已经不更新) 升级到了 @alifd/next，并在此之上建立了一套前端组件库体系。将 Lazada Seller Center 改了模样，在 Fusion 的基础上建立了一套支持整个 Lazada B 端业务的设计规范和业务组件库，覆盖页面 500+。

旧	新

在这样一个可以说牵一发动全身的背景下，为何还敢有这种想法？

不美

美的反义词，不应该是丑，而是庸俗

不能说 Fusion 丑，但绝对算不上美，这点应该没有争议吧。

虽然也可以在大量的主题样式定制的情况下也可以做到下面这样看上去还行的效果：

但说实话，这不能算出众。导致不出众的原因，可以从 Ant Design 上面寻找，Ant Design 的许多细节实现细到令人发指，比如：

弹出窗的追踪动效
按钮的点击动效
Tooltip 的箭头追踪
NumberPicker 控制按钮放大

这些细节决定了在它上层构建出的应用品质，同样是在一个基础上进行主题和样式的调整。有 Antd 这样品质的基础，就会让在此之上构建的应用品质不会很低，自然也能够带来更好的用户体验及产品品质。

迭代

拿 Antd 的源码和 Fusion 还是有蛮大的差距的，这些差距不只是技术水平的差距，可能在 10 年前他们的代码质量是差不多的，但贵在 Antd 是一个健康的迭代状态。

Antd 已经到了 5.x，Fusion 还是 1.x。这版本后背后意味着 Fusion 从 1.x 发布后就没有大的迭代和改动。即使是 DatePicker、Overlay 这类的组件重构也是提供一个 v2 的 Props 作为差别。

这背后其实反应出的是维护者对于这个库的 Vision (愿景)，或许随着 Fusion 这边不断的组织变动，早就已经失去了属于它的那份 Vision。

所以当 Antd 已经在使用 cssinjs、:where、padding-block 这种超前到我都不能接受的东西时，Fusion 里面还充斥着各种 HOC 和 Class。

可以说，Fusion 已经是一个处于缺乏活力，得过且过的维护状态。如果我们不想让这种封闭结构所带来的长期腐蚀所影响，就需要趁早谋求改变。

性能、稳定

得益于上述许多“耗散结构”的好处，Antd 的性能也比 Fusion 要好上许多。许多能够使用 Hooks、CSS 解决的问题，都不会采用组件 JS 来处理，比如 responsive、space 等。

稳定性，既体现在代码的测试质量，又体现在 UI 交互的表现稳定性。比如，Dialog、Tooltip 随着内容高度的变化而动态居中的问题（ Fusion overlay v2 有通过 CSS 来控制居中，已经修复）。在很长一段时间内，我们的开发者和用户都承受着元素闪动带来的不好体验。

还有诸如 Icon 不对齐、Label 不对齐，换行 Margin 不居中等等，使用者稍微不注意打开方式，就会可能出现非预期的表现，这些都需要使用者花费额外的精力去在上层处理修复。有些不讲究的开发者就直接把这些丢了用户，又不是不能用。

“又不是不能用” ， 而我们不想要这样

投入

Antd 的投入有目共睹，一个 86K star，超过 25K 次提交的库，与 Fusion 的 4.4K star、4K commits。这种投入的比例完全不在一个量级，这还没有计算围绕 Antd 周边丰富的文档、套件等投入。

都是站在巨人的肩膀上，都是借力，没有理由不去选择一个活跃的、周全的、前沿的、生态丰富的巨人。

为什么这变成了问题？

那既然我都把 Antd 吹成这样了，为什么这还需要思考，这还是个问题？无脑换不就行了？

现有生态

或许社区的 Antd 生态非常强劲。但在内部，我们所有的生态都是围绕 Fusion 在建立。包括：

设计规范
业务组件（50+ 常用）
模板 20+
发布体系
业务 External
... 等等许多

切换 Antd，意味着需要对所有现有生态进行升级改造，这将会是一个粗略估计 500+ 小时巨大的投入。

这将意味着我们会拦一个巨大的活到身上，做好了大家用，做不好所有人喷。

影子很重

我们都会发现一个问题，所有 Antd 来做的业务都一眼能被认出来这是 Antd。

因为它太火了，做互联网的应该没有人没见过 Antd 做的页面吧。

辩证的来看，Ant Design 它就叫 “Design”，引入 Antd 还不要它的样式，那你到底想要什么？

“想要它的好看好用，还想让他看上去跟别人不一样”

别急眼，这看上去很荒谬，但这确实是在使用 Antd 时的一个很大诉求。

我认为 Antd 应该考虑像 Daisyui 这样提供多套的主题预设。

不是说这个能力 Antd 现在没有，相反 Antd 5 提供了一整套完整的 Design Token。

但插件体系或者说开放能力，真的需要在官方自己进来做上几个，才会发现会有这么多问题 😭

这就跟 Vite 如果不自己做几个插件，只是提供了插件系统，那它的插件系统大概率是满足不了真正的使用者的。

反正虽然 Antd 5.0 提供了海量的 Design Token，但我在精细化调整样式主题时，还是发现了许多不能调整的地方(就是没有提供这样的 TOKEN 出来)。

因为 cssinjs 的方案，说实话我也不知道应该用什么样的方式进行样式改写才算是最佳实践。

CSS 方案

可以说，近一两年，随着 Vue 3、Vite、Tailwind CSS 等项目的大火🔥，又重新引起了我们对样式的思考。

Unstyled 这个词反复的被 Radix UI、Headless UI 等为首的项目提及，衍生出来的：Shadcn UI、Ark UI 等热门项目都让人有种醍醐灌顶的感觉。

大概是从 React、Vue 出现开始，UI 的事情就被绑定在了组件库里面，和 JS 逻辑都做好了放一起交给使用者。

但在此之前，样式和 JS 库其实分的很开的。如果你不满意当前的 UI，你大可以换一套 UI 样式库。同样是一个 <button class="btn"></button>，换上不同的 CSS，他们的样式就可以完全不一样。

但前端发展到了今天，如果我想要对我们的样式进行大范围升级，从 Element 换到 Ant Design 很可能涉及到的是技术栈的全部更替。

所以面对 cssinjs，我不敢说这是一个未来的方向，我花了很长时间去了解和体会 cssinjs，也确实它在一些场景中表现出了一些优势：

按需加载，我不用再使用 babel-plugin-import 这类插件
样式不在冲突，完美prefix+ :where hash样式 Scope 运行时计算，必不冲突。微前端友好！
ES Module，Bundless 技术不断发展，如果有一天你需要使用 ES Module，你会发现 Antd 5.x 这个组件库不需要任何适配也可以运行的很好，因为它是纯 JS
SSR，纯 JS 运行，也可以做 CSS 提取，InlineStyle 也变得没有那么困难

但说实话，这些方案，在原子化 CSS 中也不是无解，甚至还能做的更好。

但 Ant Design 底层其实也是采用 Unstyled 方式沉淀出了一系列的 rc-* 组件，或许有一天这又会有所变化呢，谁知道呢。

总之，我非常不喜欢使用 Props 来控制 Style这件事情。

也非常不喜欢想要用一个 Button，在移动端和 PC 端需要从不同的组件库中导入。

所以，有答案了吗？

说实话，这个问题，我思考了很久。每次思考，仿佛抓到了什么，又仿佛没有抓到什么，其实写这篇文章也是把一些思考过程罗列下来，或许能想的更清楚。