发布于 2026-01-06 8 阅读
0

Tailwind CSS 赢得了战争……但我们却是输家!DEV 的全球展示挑战赛,由 Mux 呈现:展示你的项目!

Tailwind CSS 赢得了战争……但我们却是输家

由 Mux 主办的 DEV 全球展示挑战赛:展示你的项目!

这周我需要给一个按钮添加一个简单的悬停效果。没什么特别的,就是鼠标悬停时改变背景颜色。

我盯着屏幕看了30秒,手指悬在键盘上方,却怎么也想不起来该怎么写。

并非因为我CSS技术不好。我从2017年就开始做网站了。我懂CSS。或者说,我曾经懂。

我就是想不明白语法。我脑子里立刻浮现出hover:bg-blue-600……那是 Tailwind CSS,不是 CSS。

我突然意识到,我已经大概两年没写过真正的 CSS 了。现在所有东西都用 Tailwind 了。类、工具类,没有样式表。

而且我不是唯一这么认为的人。Tailwind 每周在 NPM 上的下载量超过 2000 万次,比 Bootstrap 的 490 万次还要多。这个框架无处不在,你最喜欢的网站和代码代理都在使用它。

但这里有一个没人问的问题:如果我们都忘记了 CSS 的实际工作原理,会发生什么?

一场谁也没想到的收购

五年前,Tailwind 还是一些人尝试使用的一种略显怪异的实用工具优先框架。大多数开发者看到的代码都是这样的:

<button class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded">
  Click me
</button>
Enter fullscreen mode Exit fullscreen mode

他说:“这太恶心了。这只是多了几个步骤的内联样式而已。”

他们的说法并非完全错误。

但后来发生了一些事。开发者们开始使用它。然后他们就停不下来了。最后他们甚至忘了不用它该怎么开发。

数据说明了一切。根据CSS现状调查,Tailwind的留存率高达70%以上。这意味着四分之三的开发者在试用后会继续使用它。

相比之下,Bootstrap 的使用率约为 45%。而纯 CSS 的使用率……嗯,人们不会“保留”CSS,因为它不是可选项,而是基础。

但现在这成了一种选择。而开发者们正在选择 Tailwind。

为什么每个人都在用它(包括我)

我不会坐在这里假装 Tailwind 不好。我一直在用它。每个项目都用。现在我的肌肉记忆是 Tailwind 类,而不是 CSS 属性。

它获胜的原因如下:

速度

你无需在 HTML 和 CSS 文件之间切换。所有内容都在那里。看到一个 div,设置它的样式,然后继续下一步。无需在文件之间跳转。无需命名类名。无需担心某个元素是否.button-primary已在其他地方定义。

一致性

你的间距保持一致,是因为你使用了预定义的间距工具。p-4内边距始终相同,gap-8间距始终相同。这并非margin: 23px因为你凭感觉调整间距。

不给事物命名

给 CSS 类命名是编程中最难的问题之一。而使用 Tailwind,你无需命名任何内容。类名本身就能描述它的功能,flex items-center justify-between准确地告诉你它的作用。

就是好用

你无需费力去纠结样式特异性。你无需调试样式为何无法生效。你无需担心某个类是否在某处被覆盖。Tailwind 类就是这么好用。

它功能强大。这就是开发者喜欢它的原因。这也是我喜欢它的原因。

无人谈及的问题

但有一件事一直困扰着我,我觉得你也应该感到困扰。

我们正在抽象化基础知识

CSS其实并不难。Flexbox、Grid、定位,这些都是Web平台的核心特性,它们不会被淘汰。但我们正在培养的整整一代开发者却对这些特性一无所知。

我采访过一些初级开发人员,他们能准确地告诉我justify-content: space-betweenTailwind 类表单中的内容,但却写不出实际的 CSS 属性。

他们知道flex items-center,但又不知道align-items: center

他们知道w-64,但却不知道那是什么width: 16rem,也不知道为什么会存在。

这令人担忧。

捆绑包大小谎言

Tailwind 自诩为能够生成体积小巧的 CSS 文件包。“大多数项目最终交付的 CSS 文件都不到 10kb!”

没错,你的CSS文件很小。

但是你的 HTML 代码非常庞大。每个元素都有 5 到 15 个类。你的 HTML 文件比使用语义化 CSS 的文件大 2 到 3 倍。

没错,HTML压缩效果很好。但它仍然需要解析。浏览器仍然需要处理所有这些类。

我统计了一下我们一个项目的数据。使用 Tailwind 后,CSS 文件从 45kb 降到了 8kb,很棒!但是 HTML 文件却从 120kb 增加到了 340kb,净增加 183kb。

这一点在市场宣传中没有提到。

你被锁定了

想从 Tailwind 切换到其他框架?祝你好运。你的整个代码库都是 Tailwind 类。每个组件,每个页面,到处都是成千上万的实用类。

从 Tailwind 迁移就像从 jQuery 迁移一样。虽然可行,但过程极其痛苦,以至于大多数人干脆放弃。

你学的不是 CSS,而是 Tailwind。如果 Tailwind 消失了或者不再流行,那你该怎么办?

可读性问题

请看以下来自生产环境应用的真实代码:

<div class="flex flex-col sm:flex-row items-start sm:items-center justify-between p-4 sm:p-6 bg-white dark:bg-gray-800 rounded-lg shadow-md hover:shadow-lg transition-shadow duration-200 border border-gray-200 dark:border-gray-700 space-y-4 sm:space-y-0 sm:space-x-4">
Enter fullscreen mode Exit fullscreen mode

一个div元素里居然有19个类。你能一眼看出它们的作用吗?不能。你得仔细琢磨每个类的功能。

使用语义化 CSS:

<div class="card">
Enter fullscreen mode Exit fullscreen mode

在你的 CSS 中:

.card {
  /* All the styles */
}
Enter fullscreen mode Exit fullscreen mode

哪个更易读?哪个更容易让代码库新手理解?

如果顺风消失了会发生什么?

这件事让我夜不能寐。不是因为我觉得 Tailwind 明天就会消失。它不会消失。它现在规模太大了。

但框架来来去去。还记得Bootstrap曾经称霸网络吗?还记得jQuery几乎无处不在吗?还记得Flash是制作交互式内容的唯一途径吗?

所有这些看起来都是永久性的,但实际上没有一个是永久性的。

Tailwind 由 Tailwind Labs 支持。它是一家公司。公司可能会被收购、倒闭、转型,或者仅仅是因为某个框架不再盈利。

那么,数百万个 Tailwind 项目会怎么样呢?

你可能会说“它是开源的,社区会维护它。”没错。但是,你上一次看到一个流行的框架在失去核心团队后还能保持发展势头是什么时候?

看看 Ember,看看 Backbone,看看 Angular.js(不是 Angular,是 Angular.js)。它们在技术上仍在维护,但实际上都已经停止开发了。

我并不是预测 Tailwind 会消亡,我只是说它有可能消亡。如果它真的消亡了,那么整个开发者行业将面临无法再编写 CSS 的局面。

真正的争议(没人愿意说出口的)

接下来这个辛辣的观点可能会激怒一些人:

Tailwind 就像永远不会拆掉的辅助轮。

这是有意为之。

学骑自行车的时候,要先用辅助轮。最终,你会把辅助轮拆掉,然后真正地骑车。

使用 Tailwind 时,你一开始会用到一些实用类。然后……你会一直用这些实用类。永远用不完。你永远也摆脱不了这些辅助工具,永远也写不出真正的 CSS。

该框架并不鼓励你学习底层平台,而是鼓励你学习更多关于 Tailwind 的知识。

想做一些自定义设置?那就扩展你的 Tailwind 配置(我对新版本不太了解,别喷我,哈哈)。需要新的颜色?把它添加到你的 Tailwind 主题里。需要新的间距值?把它添加到你的 Tailwind 间距缩放里。

一切都在引导你更深入地使用 Tailwind,而不是更深入地使用 CSS。

这的确是高明的商业策略。用户锁定固然重要,但对网络平台而言却并非好事。

CSS发展迅速。容器查询、has()选择器、子网格、层叠图层,所有这些强大的功能都正在浏览器中得到应用。

但是有多少 Tailwind 开发人员了解它们?又有多少人在使用它们?

Tailwind 通过一些实用工具支持其中一些功能。但你学习的是这些实用工具,而不是具体的功能。如果 Tailwind 目前还不支持某些功能,你可能永远都不会用到它。

我正在采取的措施(以及你也应该采取的措施)

我仍然每天都在使用Tailwind。我不是来劝你停止使用它的。

但我正在做出一些改变:

每周有一天,没有 Tailwind。

星期五是我的“纯CSS日”。如果我在做项目,我会写真正的CSS代码,不用任何工具类,只写普通的样式表。

一开始确实很痛苦,但它能让我保持CSS技能的熟练度。说实话,有时候还挺让人耳目一新的。

首先教授初级CSS课程

当我指导初级开发人员时,我们不会从 Tailwind 开始,而是从 CSS 开始。Flexbox、Grid、定位,这些都是基础知识。

只有当他们能够用纯 CSS 构建布局之后,我们才会引入 Tailwind。这样他们才能理解他们所抽象的概念。

认真阅读 CSS 规范

我订阅了 CSS 的更新,阅读了新功能介绍,并在项目中进行了尝试。因为 CSS 仍在不断发展,我不想让 Tailwind 成为我了解 CSS 的唯一途径。

为复杂组件编写语义化 CSS

对于真正复杂的组件,我会编写真正的 CSS 代码。自定义属性、计算、复杂的选择器等等,这些都是工具类难以实现甚至无法实现的。

这让我无论身处哪个世界都能感到自在。

令人不安的真相

目前CSS的发展处境很尴尬。

该平台比以往任何时候都更加强大。容器查询带来了革命性的变革。级联层解决了查询优先级问题。嵌套功能终于实现了原生支持。

但如今真正编写 CSS 的开发者比以往任何时候都少。

Tailwind 正在取得胜利。数据证明了这一点。用户采纳率证明了这一点。社区也证明了这一点。

也许这样也挺好。也许抽象就是一种进步。我们抽象掉了汇编语言。我们抽象掉了C语言。我们抽象掉了jQuery的跨浏览器兼容性问题。

或许将 CSS 抽象化是下一步合乎逻辑的做法。

但我始终无法摆脱这种感觉:我们正在失去一些重要的东西——理解和操控网络底层的能力。

当每个人都知道 Tailwind 而没有人知道 CSS 时,谁来维护 Web 平台?

谁参与制定 CSS 规范?谁提交浏览器 bug?谁推动 CSS 发展?

如果答案是“没有人,因为我们都在使用 Tailwind”,那就成问题了。

CSS 的未来究竟在哪里?

当我们都在编写代码的时候flex items-center justify-between,CSS 本身也在不断发展,变得更加强大。

原生嵌套功能现已推出。现在您可以使用纯 CSS 编写 Sass 风格的嵌套选择器。

容器查询允许组件根据其容器大小而非视口大小进行响应式设计。这非常重要,Tailwind 也勉强支持它,但大多数开发者并不使用它。

这个has()选择器是父级选择器。你可以根据子级元素来设置父级元素的样式。这在过去几十年里是不可能的,现在终于实现了。

视图过渡 API 可实现流畅自然的页面过渡效果,无需 JavaScript 框架。

层叠结构让你可以对样式优先级进行精细控制。你终于可以摆脱样式优先级冲突的困扰,轻松组织你的 CSS 代码了。

所有这些都是原生 CSS 功能,浏览器级别的特性,无需构建步骤,无需框架,开箱即用。

但是有多少开发者在使用这些工具?又有多少开发者知道这些工具的存在?

Tailwind 为其中一些功能添加了实用工具,但速度很慢,而且只有在符合他们以实用工具为先的商业模式时才会这样做。

与此同时,原生 CSS 的发展速度远超任何框架所能跟上的速度。

我们应该问的问题

不再是“我该不该用Tailwind?”这个问题了。这个问题已经过时了。我们大多数人都在用或者将来都会用。

问题是:“如何在不忘记平台的情况下使用 Tailwind?”

因为真正的风险就在于此。并非说 Tailwind 不好,而是它太好了,以至于我们不再去了解它背后的原理。

当下一个重大事件发生时(它一定会发生),我们将毫无准备。

我们将成为 Tailwind 开发人员,而不是 Web 开发人员。

而这种差异至关重要。

我的真实感受(使用 Tailwind 三年后)

我并不讨厌 Tailwind。我每天都用它。它让我的工作效率更高。我的团队也因此提高了工作效率。

但我担心这个行业。担心那些认为 CSS 只是 Tailwind 类的初级开发人员。担心那些对单一框架依赖性过强,以至于无法迁移的代码库。

展望未来,“前端开发人员”意味着“了解 Tailwind”,而不是“了解 Web 平台”。

也许我错了。也许这只是进步,而我只是像个老头子对着云朵咆哮一样,怀念起编写 CSS 文件的日子。

但我并不这么认为。

我认为我们是在用短期生产力换取长期知识。而这种权衡只有在 Tailwind 永远占据主导地位的情况下才有意义。

这是一个很大的假设。

你可以做什么

如果你正在使用 Tailwind(你很可能正在使用),以下是我的建议:

不要停止学习CSS。花时间研究实际的属性。理解你所抽象的概念。阅读CSS规范。尝试新的特性。

在教授 Tailwind 之前,先教初级程序员 CSS。确保他们在学习抽象层之前理解 CSS 的基础知识。

偶尔写点原生 CSS 代码,保持技能熟练,说不定哪天就用上了。

密切关注原生 CSS 的发展。这个平台变化很快,不要只依赖 Tailwind 来了解它。

预留一些迁移空间。不要让整个代码库 100% 都使用 Tailwind CSS。保留一些自定义 CSS。即使迁移的可能性不大,也要确保迁移的可行性。

质疑框架。Tailwind声称某些做法是“最佳实践”,并不意味着它就是最佳实践。对你正在构建的东西进行批判性思考。

底线

Tailwind 赢了。数据证明了这一点。采用率也证明了这一点。如果你在 2025 年还反对 Tailwind,那你已经输了。

但胜利并不意味着完美,受欢迎也不​​意味着这就是最终答案。

CSS是平台,Tailwind是工具,不要混淆两者。

使用工具,但要尊重平台,学习平台,并为平台做出贡献。

因为当下一个框架出现时(它一定会出现),这个平台依然会存在。

你需要知道这一点。


你的看法呢?你是不是也忘了CSS?还是我想太多了?

留下你的想法。让我们像开发者一样在评论区讨论吧。

Elvis Sautet

关注我的x 账号 @elvisautet

高级全栈开发工程师 | 偶尔也写 CSS

如果你觉得不舒服,那就对了。但还是要说出来。我们需要这样的对话。

文章来源:https://dev.to/elvissautet/tailwind-css-won-the-war-but-were-the-losers-4877