Tailwind CSS 的功与过，为何有人喜欢有人烦-51CTO.COM

Hello，大家好，我是 Sunday。

说起 Tailwindcss 很多同学应该是熟悉的，它被称之为是一个 原子级 css 框架，在之前我录制的 Vue3 中前台解决方案 这个课程中，就是使用的这个 css 框架。

不过，很多学生在使用这个框架的时候，产生了两种截然不同的情绪：

这两种截然不同的情绪其实就反映出了 目前开发者对 tailwindcss 的看法。

那么为什么会出现这两种截然不同的体验，tailwindcss 到底值得用吗？

想要搞明白这些，那么首先，我们需要先知道为什么会出现 tailwindcss，也就是 tailwindcss 解决了什么问题？

tailwindcss 解决了什么问题？

Tailwind 是 2017 年发布的，最初发布的目的就是为了解决 CSS 维护困难的问题，这些问题大致包含三部分：

css 取名困难：这是一直非常核心的痛点。因为 css 多数情况下是基于 class 进行构建的。那么就会导致我们需要设置大量的 class 名。这就导致 “取名困难症” 的出现。当初甚至还出现了 css类名大全 这种网站或库。
频繁的切换视图：传统的 css 构建 html 和 css 是 分开的。这就需要开发者不断地来回切换对应的视图。
灵活性不足：在大型项目中，我们经常会发现自己在不同的组件中重复定义相似的样式。这就可能导致样式冲突或需要频繁重构。同时由于传统 CSS 类常常过于笼统，不能很好地应对不同的设计需求。开发者需要创建大量的自定义类来覆盖原有样式。

因此 Tailwind 提供了这三种问题的对应解决方式：

细粒度控制：Tailwind 提供了数百个预定义的、可组合的工具类（utility classes），可以直接在 HTML 中使用。不需要再让你想类名了。
提高开发效率：通过使用工具类，开发者可以在 HTML 中直接定义样式，减少了在不同文件之间切换的时间，从而加快了开发速度。
避免样式冲突：由于 Tailwind 提供的类都是原子化的，避免了传统 CSS 中样式污染和命名冲突的问题。同时还提供了 可定制 的能力，我们可以通过配置文件来定制颜色、字体、间距等，以符合项目的设计需求。

看上面的描述好像是很棒的。但是 tailwindcss 也带来了很多新的问题，这些新的问题就是很多同学 “讨厌” 它的原因：

这个具体体现在两个方面：

类名堆叠：由于 Tailwind 的设计理念是直接在 HTML 中使用大量的工具类（utility classes），这可能会导致 HTML 变得“杂乱无章”，特别是在复杂的组件中，类名的堆叠可能非常庞大，影响代码的可读性。

难以理解的代码：对于没有使用过 Tailwind 的开发者来说，看到一堆无意义的类名（如 p-4, mt-2, text-blue-500）可能难以快速理解代码的意图和布局。

学习复杂度：对于刚接触 Tailwind 的同学来说，大量的类名记忆是非常消耗心力的。想要理解如何有效地配置 Tailwind 学习曲线并不低。
复用并不简单：虽然 Tailwind 提供了很多的工具类，但是在多人合作的团队中，我们可能依然需要在多个地方重复相同的类名。特别是一些初创团队，使用 Tailwind 可能导致相似的样式在不同地方多次定义，增加了维护成本。

生成的 CSS 文件较大：默认情况下，Tailwind 生成的 CSS 文件包含大量的工具类，这可能导致生成的文件体积较大，尤其是在没有使用 tree-shaking 等技术来去除未使用的样式时。这会影响页面加载速度和性能。
依赖构建工具：为了优化 Tailwind 的输出，通常需要依赖构建工具（如 PostCSS 或 PurgeCSS）来移除未使用的样式，这增加了项目的构建复杂性。

那么根据以上内容，其实我们也可以发现 Tailwind 并不适合所有人使用。

因此，也就出现了 拥抱 Tailwind 和 逃离 Tailwind，回归 scss 的两种截然不同，但又同时存在的乱象。

在前端这个领域，这种乱象并不是仅存在于 Tailwind 这一个框架，而是存在于我们日常开发的方方面面。大家应该也经常有看到 两种不同框架的开发者在网络中互相 “攻伐” 的情况。

但是，如果让我去说，我觉得：这都是 毫无意义 的！

技术本身在于 辅助业务，创造价值。

在这个过程中，业务是核心，价值是结果，技术是辅助核心完成结果的过程

大家想一想，如果我们 不去讨论核心的业务，不去追溯最终的结果，而只是在过程中来回纠结，是不是就显得有些舍本逐末了。

所以说：使用什么框架并不重要，感觉这个“工具”顺手就继续使用，不顺手就把它“丢掉”。毕竟，这只是一个过程呀~~