Tailwind 不适合我

原文 ↗ Hacker News 讨论 ↗

对 Tailwind CSS 的批评主要集中在其冗长的 utility 类、HTML “污染”，以及围绕非标准 `@apply` 语法带来的锁定问题；一些开发者认为它削弱了语义化 HTML、可访问性和长期可维护性。支持者则反驳说，Tailwind 能提升生产力，让样式与组件共置，并减少 CSS 中常见的命名、优先级冲突和样式表膨胀问题，尤其适合大型或快速开发的应用。这场争论凸显了“无聊”的原生 HTML/CSS 与新抽象之间的更广泛张力，以及在开发速度、可读性和面向未来的可维护性之间不同的优先级。

总体情绪

  • 讨论立场明显分裂：有些人认为 Tailwind 是巨大的生产力提升，另一些人则觉得它丑陋、专有，而且不利于长期维护。
  • 许多人认为，这个选择在很大程度上取决于个人工作流程、项目规模，以及对工具锁定的容忍度。

生产力 vs. 可维护性

  • 支持者认为 Tailwind：
    • 消除了为 CSS 类命名以及管理大型样式表的负担。
    • 保持了“行为局部性”——样式紧挨着标记/组件，更容易复制粘贴，也更容易推理。
    • 加快原型和 MVP 的开发，尤其适合不精通 CSS 的人。
  • 批评者认为：
    • 很长的 class 属性会变得难以阅读，尤其是一个元素上有 20–50 个 utility 时。
    • 几个月后再重构，或者由别人接手时，会非常痛苦。
    • 它助长了“div/span 汤”，语义性变弱，损害可访问性和性能。

CSS、架构与关注点分离

  • 一派强调分离：HTML 负责结构，CSS 负责样式，JS 负责行为。Tailwind 被视为向内联样式和“意大利面条式”代码倒退。
  • 另一派认为严格分离被高估了；把样式与组件放在一起能减少上下文切换，并减少 CSS 特有的坑（如优先级战争、滥用 !important）。
  • 讨论也集中在 Tailwind 是“只是内联 CSS”（批评者）还是一种受约束、由主题驱动的 utility 系统，能避免许多内联样式问题（支持者）。

锁定、工具链与可移植性

  • 有人担心 Tailwind 的 @apply 和用 JS 定义的 design tokens 是专有的，会让样式难以移植。
  • 也有人提到可以在 Tailwind 和普通 CSS 之间转换的工具，以及旨在“去 Tailwind 化”代码的项目。
  • 还有顾虑是：即便只是 CSS，也需要构建步骤和 JS 工具链；不过其他人指出，很多技术栈本来也已经有构建流水线。

Web components、custom elements 与 Shadow DOM

  • 关于是否使用 custom elements（例如 <ui-card>）来避免 div 汤也有争论：
    • 有人认为可以只把未声明标签用于语义和 CSS 选择。
    • 也有人强调这不等同于真正的 custom elements，后者需要 JS 和 Shadow DOM。
  • Shadow DOM 被批评为一种有问题的抽象，会让样式和与 Tailwind 及其他工具的集成变得复杂。

替代方案与折中做法

  • 提到的替代方案包括：PicoCSS、使用现代特性的原生 CSS、CSS Modules、Styled Components、LESS/SASS、原子化/utility 库，以及把 Tailwind 提取成普通 CSS 的工具。
  • 一个常见折中是：把 utility 用于布局/结构，把自定义类或组件用于外观与感觉；将 Tailwind 类封装进组件抽象中。

元讨论：技术时尚与“无聊技术”

  • 几条评论感叹框架不断更替，以及技术被当作时尚。
  • 有人主张使用“无聊”的 HTML/CSS/JS，不依赖沉重工具；也有人为实验辩护，并指出框架往往会影响未来的标准。