为什么我放弃了 Tailwind 的繁重 CSS 框架——以及发生了什么变化
经过多年的特殊性战争和未使用的千字节数的斗争，以下是最终说服我做出转变的原因 - 以及它对我的工作流程和客户的绩效分数产生的可衡量的影响。
传统CSS框架的问题
我花了三年时间使用 Bootstrap 和 Bulma 构建项目。它们是很棒的框架——我不会假装不是这样。但我使用它们的时间越长，我就越发现自己在与系统对抗，而不是与它一起工作。
每个新项目都以相同的方式开始：导入框架，立即覆盖一半，编写大量自定义 CSS 来撤消默认值，然后花费 40% 的开发时间调试特异性问题。最终的 CSS 包通常为 80-120kb，其中可能有 15% 被实际使用。
“当你开始写作的那一刻
!重要为了覆盖框架的默认设置，某些事情已经从根本上出错了。”
是什么让我给 Tailwind 一个适当的机会
我已经对 Tailwind 不屑一顾了很长一段时间。实用程序类方法在 HTML 中看起来很混乱，我确信它会使模板变得不可读。然后一位客户要求我维护现有的 Tailwind 项目，我别无选择。
两周后，我皈依了。这就是改变我想法的原因：
- 没有上下文切换。 我不再在 HTML 和 CSS 文件之间来回切换。一切都在标记中。
- 零特异性战争。 实用程序类都是单级选择器。你永远不会与瀑布对抗。
- 最后的小包。 PurgeCSS（现已内置）意味着生产版本通常为 5-15kb。我的平均大小从 110kb 增加到 8kb。
- 设计系统就是配置。 间距、颜色、版式——全部集中在
tailwind.config.js.
现实世界的性能影响
我使用 Tailwind CSS + Alpine.js 重建了客户的营销网站，替换了他们的 WordPress + Bootstrap 4 堆栈。一个月后的结果无可辩驳：
- 灯塔性能评分： 47 → 96
- CSS 捆绑包： 118kb → 7kb
- 第一次绘制内容的时间： 3.8s → 0.9s
- 跳出率： -22%
我仍然怀念传统框架的东西
这并不都是完美的。我仍然需要插件或自定义组件来替换一些东西：
- 预构建的复杂组件，例如模式、下拉菜单和日期选择器
- 表单验证样式（尽管 Alpine.js 很好地处理了逻辑方面）
- 自以为是的网格系统——Tailwind 的网格功能强大，但对于复杂的布局来说却很冗长
生态系统已经基本跟上了。 Headless UI、Flowbite 和 Preline 弥补了大部分空白。 Alpine.js 在不增加重量的情况下完美地处理了交互层。
我的推荐
如果您正在构建任何自定义内容（SaaS 产品、产品组合、登陆页面），Tailwind 是正确的工具。最初的学习曲线大约是一周。之后，您的发货速度将比以前更快。
如果您需要 WordPress 主题或具有最少自定义样式的简单宣传册网站，Bootstrap 仍然非常适合。使用适合工作的正确工具。
如果这有帮助，请与仍在使用 Bootstrap 4 的前端开发朋友分享。🧡
