Tailwind CSS，从入坑到退坑

Tailwind CSS 是一个实用类优先的 CSS 框架。跟其他 CSS 框架的主要不同是它不提供组件层面的样式，而是全部都是实用类。我之前写过一个简单的介绍：Tailwind CSS 浅析。

纸上得来终觉浅，绝知此事要躬行。看完文档我也很难评价 Tailwind 的理念是否可行，所以我在一个新建的小项目上尝试只用 Tailwind 开发。经过一个多月，我觉得可以总结一下使用 Tailwind 的经验。

优点

编写样式时，我首先会在纸上画出样式草稿，然后直接在编辑器编码。其中一个痛点就是怎么拆分元素命名。有的元素只是需要居中对齐，有的只是增加一些边距，本身并没有很确定的语意。然后为了实现某些效果，添加 wrapper inner container 这些命名会让我很无奈。

Tailwind 免去了命名的过程，需要什么样式直接在 class 里面写，增加了开发效率。

Tailwind 提供 Standalone CLI 的安装方式，不需要安装 node，没有外部依赖。tailwindcss-rails 就是用这种方式安装。

Tailwind 有大量预置的样式，例如颜色（bg-blue-*），尺寸（max-w-*)，阴影（shadow-*）等等。写样式的时候直接用这些样式，不用从零开始找调色板或者逐个像素调整。

我在 Tailwind 上手阶段基本没遇到什么问题，添加了一些基本的组件样式之后，开发效率就跟用我维护的一个组件库差不多了。当时我觉得 Tailwind 可以成为我的主要样式框架一直用下去。

随着开发深入，我感受到 Tailwind 的一些缺点。

有很多样式是使用率很高，又不足以抽取公共模版的，这时候最好是抽取组件样式，例如 button，card 等等。而这些组件样式越写越多，逐渐写了两百多行，这时候就遇到下一个问题。

组件样式增多的时候，我想能把组件样式拆分文件。但是 Tailwind 本身不支持多文件合并，官方文档对此的建议是使用 postcss，把 Tailwind 作为插件使用。这样就违背了我减少依赖的想法。

从作者以前的回答来看，他认为如果有很多组件样式的需求，那么就不适合用 Tailwind。我觉得如果支持多文件合并，Tailwind 就可以跟其他 CSS 管理方法共存了，这大大增加了框架的适应性，不知道作者以后是否会改变想法。

虽然在初次编写的时候使用预置的 token 很方便，但是第二次就麻烦了。上次用的颜色是什么，边距是什么？我需要反复打开一切写过的组件确认，避免产生样式的不一致。这时候我开始怀念以前的做法，用 button--primary form__field 等样式可以确保整站的样式一致。

当然 Tailwind 可以通过配置文件增加主题化的实用类来实现同样的效果。但与其改 Taiwind 的配置文件，还不如直接写 CSS。

对于复杂的显示逻辑，直接编写 CSS 更简单。例如有一个编辑器样式，当编辑器处于预览状态的时候，所有格式化按钮要变成灰的。在 CSS 中可以这样表示：

.editor--priviewing .editor__button {
  pointer-events: none;
  opacity: 0.5;
}

Tailwind 不适合处理这样的任务。

最好的代码不是为编写优化，而是为阅读优化的。我还是觉得 Tailwind 的一大串样式很难阅读。我没有信心把自己写的一大串 Tailwind 代码交给别人维护，也不想维护别人写的一大串 Tailwind 代码。

经过一个多月的尝试，我最终还是决定弃用 Tailwind，回到 Scss 的怀抱。

我在使用 Tailwind 的过程也学到不少东西。实用类确实能增加一些开发效率，所以我在自己维护的样式库中增加了不少实用类。Tailwind 的经验可以让我更好的维护实用类。

最后要指出，我写这篇文章并不是推荐或不推荐使用 Tailwind，因为每个团队的需求和流程不一样，也许有的场景特别适合使用 Tailwind。我觉得 Tailwind 作为这几年最火的 CSS 框架，不尝试一下会有点可惜。

希望这篇文章能给你提供参考。