TailwindCSS 作者谈开发初衷

知乎 已发布

知乎问题：如何评价CSS框架TailwindCSS？

原文：CSS Utility Classes and "Separation of Concerns"

作者有多年工作经验，其对待 CSS 的心路历程如下：

第一阶段：语义化 CSS

特点：以 CSS 在 HTML 中的语义来命名 CSS 类名

缺点：HTML 达到了「分离关注」的目的，无需关心 CSS 了，但是 CSS 的结构与 HTML 的结构强耦合，几乎就是 HTML 结构的复刻。

第二阶段：将「样式（CSS）」与「结构（HTML）」解耦

典型代表：BEM 方法论

实际工作中，面临的两难境地：

语义化 CSS

特点：HTML 是独立的，CSS 依赖 HTML
导致的结果：HTML 可以方便地调整样式，CSS 不能方便地重用。

内容中立（content-agnostic）组件

特点：CSS 是独立的，HTML 依赖 CSS
导致的结果：CSS 可以方便地复用，HTML 不能方便地调整样式。

关键洞见：

每个项目负责人都要意识到，「分离关注」并非是一个非黑即白的选择，而是一个权衡（tradeoff），一边是方便地调整样式，一边是方便地复用样式。

考虑到
1. HTML 是结构化的信息，具有明显的约束（如：标签种类等）
2. CSS 是创造性灵感类信息，有极大的发散空间，达成相同效果有多种方式，无约束且易被滥用，被滥用后容易导致 UI 的不一致性

作者坚定的选择

「方便地复用 CSS」，为 CSS 增加约束，提升 UI 一致性。

第三阶段：内容中立组件

作者的观察：

一个组件做得越多，或者一个组件越具体，越难以复用

注：粒度越粗，越难复用。

第四阶段：内容中立组件 + 功能类（utility classes）

作者的观察：

通过细粒度的功能类的组合，可以有效去除 CSS 中的重复

第五阶段：功能类优先（Utility-first）CSS

所有的 CSS 均由功能类组合而成
好处：对 CSS 的使用施加约束，有利于产生更一致的 UI

但是如果一个组件频繁被使用，却每次都要用功能类组合而成么？

• 用功能类组合成组件
• 避免过早抽象
  注：这里有个很好用的规则：直到一个模式出现 3 次的时候，再考虑抽象成组件，而非像 BEM 等方法论所做的那样，一开始就提供组件。