共计 3930 个字符，预计需要花费 10 分钟才能阅读完成。
Tailwind CSS 是一个工具集 CSS 框架，网上很多文章已对其有详尽的介绍。本文不是官网文档的复述，也不是系列长处的列举，作者 Gerard 会从另一个角度登程，在尽力放弃主观的前提下，立足于理论开发的场景，指出 Tailwind CSS 存在的一些问题。事实上，除了文中提及的，Tailwind CSS 还存在着不少毛病，比方对高度定制化的反对水平有余、记忆大量预约义类名带来的心智累赘等。
情谊揭示，你不肯定会同意这篇文章的认识 ，毕竟咱们的认识总会受到本身认知和应用体验的影响，但更重要的是可能是作者对新兴技术的态度，用他的原话说，就是：“When everyone is shouting that it’s awesome, it’s usually a good moment to sit down and have a good look at it”
上面注释开始。
- 原文地址：Tailwind CSS Is (Probably) Overhyped Overhyped”)
- 原文作者：Gerard van der Put
- 译者：Chor
引言
在过来的两年间，Tailwind CSS 广受青眼（从每周 30K 的下载量到现在的 600K）。毫无疑问，这个风行的实用优先 CSS 框架具备诸多长处。很可能你对它的惊艳和弱小早有耳闻，因为很多开发者正是这么想的。
但对于这个框架，咱们还有很多要说的。
什么是 Tailwind CSS？
如果你素来没见过 Tailwind 的理论利用，能够看这个：
<div class="bg-gray-100 rounded-xl p-8">Hello World</div>这里的类名就反映了 Tailwind 的定义：一个蕴含多个预约义类（所谓的工具类）的汇合。你并不需要编写根底的 CSS 款式规定，只须要间接在 HTML 中利用曾经当时定义好的类名。
这样的类名还有很多。上面这个列表展现了局部类别和对应的例子：
- 背景 (
bg-gray-200,bg-gradient-to-bl) - 弹性布局 (
flex-1,flex-row) - 网格布局 (
grid-cols-1,col-span-4) - 内边距 (
p-0,p-1) - 尺寸 (
w-1,h-1)
之前有人将这个预约义类的汇合比作能够在代码中应用的“乐高积木”。当然，它与传统的 CSS 有很多反复之处，但却不止于此：比方它还包含了预约义的范畴（bg-red-100, bg-red-200 等）。Tailwind 旨在让咱们的开发事倍功半，从某个角度来说，它也的确做到了。
同时，我很喜爱这个名字：Tailwind（逆风）。我闲下来的时候会驾船出海，逆风可是个不错的货色。
语法
正如下面所展现的，咱们间接在 HTML 中书写工具类名。咱们会很快想到这和内联 CSS 是十分类似的，这或者也能解释为什么 Tailwind 的开发者会在文档的结尾局部就提及这个问题。
尽管他们竭力解释，称 Tailwind 瑕不掩瑜（我不否定它的确有诸多长处），但我还是不太认可它的语法。我不想用一大堆类名净化 HTML 构造中的每一个元素，也不想每天都面对这样的代码：
留神：下面这段代码来自 Tailwind 的文档，所做的事件是渲染一个简略的卡片。事实上，它最初出现的成果十分丑陋，甚至还是响应式的。但如果放眼于咱们的日常开发，这种状况就会急速好转：如果我正在开发一个比卡片简单更多的组件呢？如果我必须遵循设计师提出的某种设计格调，以及忍耐他的一些“小怪癖”呢？
我尝试去应酬这种状况，后果也在意料之中 —— 每一个 HTML 元素都充斥着一大堆 Tailwind 的工具类名。官网文档和教学视频并不会通知你这些，但在咱们着手开发大型利用的时候，这会是一个实在摆在咱们背后的问题：
// 一大堆类名
<div class="sm:w-4 md:w-6 lg:w-10 xl:w-full sm:text-sm md:text-base lg:text-base xl:text-2xl flex-1 sm:flex-none bg-black sm:bg-white rounded-md sm:rounded-none">Hello World</div>这也是理论开发中不可避免的。
下面这个例子可不夸大，我甚至能够说它是一个最简化的例子了 —— 至多对于那些有明确要求、明确设计格调（基于不同屏幕尺寸作出的响应式变动和款式调整）的利用来说，是这样的。
那么要怎么组织这些类名呢？兴许咱们要创立并遵循某个排序规定，但这样切实太简单了。另一种做法是容许模板设计者和开发者应用任意一种具体的排序，但这样一来，为了找到要批改的指标类名。咱们就不得不程度扫视甚至是滚动查看代码。
我可不想像找威利一样去找元素的字号 （译者注：威利是儿童书籍《威利在哪里》中的人物，读者须要在一张三三两两的图片中找到威利）
我的观点是，局部 HTML 元素会应用十分多的款式，这种状况下应该思考将款式与 HTML 标签进行拆散，独自放到某个文件里。这样，咱们就能够组织款式并加强其可读性。你不能把 CSS 的所有性能”塞到“class 这一个 HTML 标签属性里，Tailwind 也不能。这样做只会让 HTML 构造越发臃肿。
@apply
针对下面提到的问题，Tailwind 容许咱们在单个 CSS 文件中应用它们的类名：
.header {@apply bg-red-200 w-4 text-gray-400 rounded-sm border-red-400 border-2;}但比起传统编写 CSS（或者 SASS 等其它预处理器）的形式，我看不出这样做有什么长处。你能够说我是“老古董”，但我的确更喜爱上面这种编写形式：
.header {
background-color: #FECACA;
width: 200px;
color: #444;
border-radius: 5px;
border: 2px solid #F87171;
}再次强调，在实在开发中，元素可能会利用十分多的款式。
我并没有对 Tailwind 的长处避而不谈，其提供的局部工具类肯定有更多用处亟待摸索。但谈及语法的时候，我还是心愿标记语言（HTML）和款式规定能够进行明确的拆散。我想，这是一个主观的认识。
革除无用代码
在我的项目中引入 Tailwind 之后，所有的类名都是可用的。但在构建和打包我的项目的时候，咱们显然并不需要用上所有类名。因而，Tailwind 应用了 PurgeCSS 这个工具：
这就是 PurgeCSS 发挥作用的中央。PurgeCSS 会剖析你的内容和 css 文件，首先它将 css 文件中应用的选择器与内容文件中的选择器进行匹配，而后它会从 css 中删除未应用的选择器，从而生成更小的 css 文件。
简略总结一下：首先，咱们为我的项目引入大量的工具类名，接着，在筹备构建并公布我的项目的时候，应用一个工具扫描代码并找出所有未应用的类名，以确保它们不会随其它代码一起打包。其实现依赖于上面这个正则表达式：
引入并应用 Tailwind 会给咱们的我的项目平添一层复杂性，复杂性带来的是肯定的危险，会给咱们的开发造成麻烦。比如说：
render(
myItems.map(item => (<div className={`item level-${item.level}`}>
{item.text}
</div>
));
);像这样动静生成类名的操作是做不到的。这意味着 Tailwind 对咱们的开发造成了限度。对于这一点，文档也有提到，但很容易被开发者疏忽：
字符串拼接的操作是不容许的。
开发上的限度是一方面，还有一个问题是：给我的项目减少一层复杂性，通常会给我的项目带来危险。
这最终变成了一个关乎判断的问题，即 Tailwind 是否利大于弊？我的项目不同，对这个问题的答复也不同，但咱们至多得留意到它存在的问题。对于 Tailwind 带来的限制性，下面提到的问题只是冰山一角。能够再举一个例子，那就是给 Tailwind 我的项目增加额定的（自定义的）CSS 并不那么简略间接。
替代品
在浏览了 Tailwind 的文档并上手开发了几天之后，我忍不住在想：作者并没有意识到咱们中的大多数人曾经在日常开发中应用其它工具来简化款式编写了。
文档说过，应用 Tailwind 的一个益处在于能够防止魔数（译者注：魔数指的是不足解释或命名的独特数值，呈现屡次，且能够被有名字的常量取代）。的确如此，这是它的一个长处：咱们定义一个诸如 bg-red-200 的色彩工具类，之后能够在代码各处应用，并在一个中央（Tailwind 的配置文件）集中批改它的理论值。这还是挺香的，我置信你也批准这种做法。
但明天的工具，比如说 SASS（周下载量超过五百万），早就能够轻松创立工具类和变量并在代码中重用了。甚至原生的 CSS 也曾经反对应用变量。
当咱们应用 SASS 或者原生 CSS 的时候，咱们不须要面对额定的一层复杂性，在编写 CSS 款式规定的时候，也不须要扭转既已造成的习惯和语法。
应用 Tailwind 是有老本的。破费工夫和精力学习 Tailwind 的语法和类名，你会逐步遗记其背地的语法：也即原生 CSS 的语法。如果我的开发者在一个更大的我的项目中应用 Tailwind 长达一年，他们将会逐步遗记原生 CSS。这种事态真的乐观吗？我不太确定。
后序
Tailwind 很风行，它的吸引力和追捧者一劳永逸。我能了解这其中的起因，毕竟应用它真的能够让咱们受益匪浅。对其长处我也示意认可，它的一些工具类能够施展很大的作用。
我撰写本文的目标，在于向各位展现一个事实：故事总是有两面性的。
一些人会从这个框架中受害，但还有一些人则会受限，他们会在开发的过程中一直发现这些限度 —— 或者更糟，在开发后才发现。
在适应新框架的时候，请放弃你的批判性。当“每个人”都高声惊呼其惊艳的时候，兴许正是沉着坐下、认真打量的最佳时机。
感激你破费工夫浏览本文！
