照片由Unsplash上的Khamkéo Vilaysing拍摄
CSS 及其用于匹配 DOM 元素模式的选择器语言旨在解决与我们在 Culture Amp 的 Web 应用程序代码库中面临的问题不同的问题。
如果您需要为一个充满文档的网站提供一个样式表，这些文档将独立于您的样式而增长和发展，其中内容会因文档而异，即使样式需要在它们之间保持一致，那么一组 CSS 选择器为那些独立编写的文档描述一致的风格规则正是您所需要的。 Tailwind CSS 对于这项工作来说是一个很糟糕的工具，因为它会让您重复相同的类名组来将一致的样式应用于 HTML 中的元素。
另一方面，如果您正在构建一个 Web 应用程序，其图形用户界面已经由 JavaScript 组件（例如 React）组成，那么您已经消除了 HTML 中与这些组件的重复。 Tailwind 是完成这项工作的完美工具，因为它使您不必与 JavaScript 组件并行维护一组 CSS 样式，并与这些组件生成的 HTML 紧密耦合。
虽然将 UI 样式与 UI 组件分开可能感觉整洁且高效，但实际上，对 UI 组件的大多数更改都需要对其样式进行相应的更改，反之亦然。因此，通过在两个地方维护紧密耦合的代码，您所做的一切就是为自己和浏览器创建不必要的工作，浏览器必须解析和应用更多的 CSS，因为每个组件最终都会有自己的样式规则，即使它的风格实际上并不那么独特。
Culture Amp 采用 Tailwind 的决定
我最初编写了下面的基本原理，作为我们决定于 2022 年中期在 Culture Amp 采用Tailwind CSS的内部解释。
当时，我们一直在使用Sass编写 CSS，并使用古老（并且仍然优秀）的CSS 模块对其进行编译。通过这种方法，我们遇到了各种令人痛苦的规模症状，即样式表包大小、构建性能和开发人员体验，是时候考虑其他选项了。我们考虑的两个是Vanilla Extract ，它本质上是我们在 SEEK 的朋友提供的更现代且功能丰富的 CSS 模块，以及Tailwind CSS – 一种有争议且可能引起分裂的技术，它违背了数十年的 CSS 教条，表面上是为了提供更高的开发人员生产力和更小的 CSS 包。
出于这些原因，截至 2022 年中期，我们决定在 Culture Amp 尝试使用 Tailwind CSS 作为实验。这个实验很成功，Tailwind CSS 现在是 Culture Amp 向用户界面添加自定义样式的标准方法，但以下是我当时写的内容：
基本原理
Tailwind CSS 的承诺是，它在很大程度上消除了编写新 CSS 的需要，这不仅可以解决我们不断增长的包大小和构建时间（我们放弃 Sass CSS 模块的一些主要驱动因素），而且可以大大减少认知负荷并改善构建 UI 的工程师的开发体验 (DX)。他们不再需要为每个元素和变体设计一个有意义的类名，也不再需要跨两个文件将样式连接到其 HTML。
不需要想出一个有意义的类名（工具栏）：
<div className={styles. toolbar }>
…然后将其添加到您的样式表中：
.toolbar { display : flex; }
…Tailwind CSS 只是为您提供了一个预先确定的类名来执行此操作，以及您需要使用 CSS 执行的几乎所有其他操作：
<div className= "flex" >
Tailwind CSS 知道flex的含义，并为您生成必要的 CSS，并且它只需执行一次即可覆盖整个应用程序中的每个display: flex实例！您可以向元素添加多个类名，大约为每个要设置的 CSS 属性添加一个类名，而不是使用将多个样式属性应用于元素的单个类名。而且您永远不需要为您的样式打开单独的文件。
Tailwind CSS 的核心思想是，我们今天编写的 CSS 99% 都是不必要的重复，用与 HTML 内联的高级语言可以更好地表达，紧密耦合是不可避免的。即使你喜欢 CSS 并喜欢编写和维护它 [我就是这么做的 –Kev]，Tailwind 认为这通常不是很好地利用我们的时间。
这是一个有争议的想法，因为我们大约有一半的工程师非常喜欢 CSS，或者至少对自己在这一领域的技能进行了投资并为此感到自豪。我们不仅被教导要避免内联样式，并将内容和表示的关注点分开，而且 Tailwind CSS 将缩写类名组成长字符串的语言对我们来说是陌生的，并且违背了我们对代码可读性的所有本能。
但是，如果 Tailwind CSS 的理论在 Culture Amp 工程师的实践中被证明是正确的（之前使用过它的露营者的经验表明它会如此），那么 Tailwind CSS 对我们的生产力和代码的可维护性的积极影响可能比我们的任何替代方案都要大得多。都知道。潜在的胜利足够大，我们欠 Tailwind 一次机会。
推荐观看： Simon Vrachliotis 带领您走进“实用至上”CSS 的现实生活之旅
推荐阅读： 从语义 CSS 到 Tailwind – 重构 Netlify UI 代码库
当然，没有什么是免费的。 Tailwind CSS 有效地向我们的工具链引入了一个新的编译器（以及用于自动完成、格式化和 linting 的相关编辑器集成），它可以识别我们使用的类名，从而仅生成必要的 CSS 输出。因此，Tailwind 要求我们熟悉并注意源代码的另一个使用者的限制（例如Tailwind 无法识别动态构造的类名）。所需的心智模型比我们所需的 Sass CSS 模块简单得多，但并不像Vanilla Extract提供的“这只是 TypeScript”体验那么简单。
此外，虽然 Tailwind CSS 极大地降低了“通用”样式的成本，但它使我们失去了一些用于编写可维护的自定义样式的工具。例如，没有工具可以将样式范围限定为单个组件（例如，CSS 模块中的散列类名，或 Vue 等框架中的前缀类名）。 Tailwind 的文档为此使用了 BEM 命名约定，我们从经验中知道，这种命名约定在拥挤的代码库中无法很好地扩展。假设您想将组件特定的样式与组件一起放入 CSS 文件中，则必须将其@import到中央 CSS 文件中（不能只从组件导入它）。一般来说，编写自定义 CSS 的人体工程学要差得多，但 Tailwind CSS 承诺编写此类代码的需要变得极其罕见。今天的PostCSS确实为我们提供了一些我们过去需要 Sass 才能实现的功能——混合和选择器嵌套——以及 CSS 自定义属性取代了 Sass 变量。
Vanilla Extract是我们考虑的主要替代方案，相比之下，它在很大程度上增加了 CSS 模块的权衡，但在工具包中添加了类型安全和 JavaScript 逻辑。虽然这些都是非常有吸引力的属性，但不幸的是，它在认知负载方面并没有像 Tailwind CSS 那样提供巨大的胜利，也无法对抗我们在 CSS 模块中经历过的大包大小，其中每个新组件都会增加我们的 CSS 输出。 Sprinkles是 Vanilla Extract 用于生成实用程序类的附加库，如果我们使用它来设计我们自己的样式 API（与 Tailwind CSS 一样强大），则会生成不合理的大 CSS 输出，并且没有实用的方法从我们的包中清除未使用的样式。 Vanilla Extract 的维护者已向我们确认，他们不打算在可预见的将来解决这个问题。
根据我们最初的概念验证实验，Culture Amp 工程师的反馈表明，Tailwind CSS 很可能会在我们的应用程序代码库中提供预期的生产力提升和减少的包大小，但在我们的设计系统代码库中，我们可能会发现需要自定义 CSS 的重要性足以使 Tailwind CSS 成为净负债。特别是，我们当前为视觉回归测试模拟伪状态（悬停、焦点等）的方法很难用 Tailwind CSS 的实用类语言以及具有应用样式的复杂逻辑的组件来复制，或者我们需要在更专业的组件中覆盖基本组件样式，在我们的第一次尝试中似乎无法很好地扩展。
[注：自从我在 2022 年写下这篇文章以来， Storybook Pseudo States 附加组件解决了伪状态的挑战，但我们的设计系统组件的 CSS 确实仍然需要比 Tailwind 轻松管理的更复杂的逻辑，因此Kaizen目前已继续使用 CSS 模块。]
如果我们尝试 Tailwind CSS 并发现我们仍然需要编写足够的自定义 CSS，而我们错过了 CSS 模块来保持它的组织，那么 Vanilla Extract 可能是一个很好的后备选项。它将让我们使用 Sprinkles 来满足 80% 的样式需求，而使用一组不太完整的实用样式，然后使用框架的一流自定义样式支持来满足剩余的 20%。但设计、维护和记录该实用程序风格的框架将取决于我们，而且我们不太可能赶上 Tailwind 已经提供的开发人员体验。
与此同时，Tailwind继续稳步消除每个版本中自定义 CSS 的用例。
原文： https://kevinyank.com/posts/why-we-use-tailwind-css-at-culture-amp/