Tailwind CSS 营销与误导引擎
Tailwind CSS 的“utility-first”网页界面样式设计方法在开发者和设计师之间引发了强烈分歧。批评者认为它复活了内联样式的反模式，破坏了关注点分离，把团队锁定在某种特定于供应商的 DSL 中，并让大型代码库更难理解，尤其是在设计系统和跨角色协作方面。支持者则反驳说，它通过消除全局 CSS 的陷阱、减少命名负担，并让样式与标记紧密结合，显著提升了基于组件应用的生产力和可维护性；许多人认为它的流行更多源于现实中的收益，而不是营销炒作。
对文章的反应
- 许多人认同关于炒作、营销和工具频繁更替的总体警告，但觉得文章过于严厉，假定了恶意意图，并且选择性地回应了 Tailwind 的论点。
- 一些读者表示，如果能提供同类对比的 CSS 示例（例如完整重做那个复杂按钮），并更清楚地区分 Tailwind 和 CSS-in-JS，批评会更有力。
- 还有人觉得文章的语气（指责“欺骗”，让用户“去学 CSS”）令人反感，也因此更不想了解作者的替代框架。
Tailwind / utility CSS 的被认为的优点
- 行为局部化：样式与标记/组件放在一起，因此无需在 CSS 文件中翻找就能看出一个元素的外观。
- 避免全局 CSS 陷阱：更少的 cascade/specificity 调试；也更不担心影响应用中无关部分。
- 在基于组件的技术栈中尤其好用（React、Svelte 等）：只需用 utility classes 定义一次
Button；通过组件复用，而不是通过 CSS 选择器复用。 - 减轻命名负担：减少临时性的语义类名；只有组件需要命名。
- 适合“web app”工作流，在这些流程里设计很少只靠 CSS 微调，通常会整体重做。
- 提供一个一致的设计系统（间距尺度、颜色、响应式工具类）以及 purge/tree-shaking。
对 Tailwind 的批评
- 有些人认为它像“多了几步的内联样式”，违反了关注点分离，并产生难以阅读的“class soup”，尤其是在没有组件时。
- 设计师和非 JS 人员反馈工作流更差：全局设计调整需要改很多 JSX/TSX 文件；类名不再能作为工具或分析的稳定挂钩。
- 原子化 utility 可能提高认知负担，在大型设计系统中不如 CSS 自定义属性顺手。
- 对依赖分层设计系统的人来说，cascade/context 的丧失被视为缺点。
语义化 CSS、组件与折中方案
- 有几位认为：语义化 CSS + 良好命名 + BEM/scoped CSS 可以解决很多同样的问题，但也承认在大团队中很难强制执行。
- 也有人说真正的分界是：以组件为中心的技术栈往往更偏向 Tailwind；静态/内容型网站更适合语义化 CSS。
- 一个常见的“中间路线”：组件使用语义类名；布局、间距以及一次性覆盖则使用 utility classes（Tailwind 或类似方案）。
流行度、营销与文化
- 有些人把 Tailwind 的崛起部分归因于营销和网红；另一些人则坚持它之所以流行，主要是因为它对许多开发者来说“确实好用”。
- 这里存在明显的两极分化：支持者把批评视为把关；怀疑者则觉得 Tailwind 的拥趸像邪教一样，而且轻视 Web 标准。