cover

Tailwind CSS,从入坑到退坑

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

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

优点

避免命名

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

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

Standalone CLI

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

预置 token

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

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

缺点

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

依然需要组件样式

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

不支持多文件合并

组件样式增多的时候,我想能把组件样式拆分文件。但是 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 中学习

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

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

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

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

6
7
1