从 Tailwind 迁移到 Vanilla-er CSS

自从 Tailwind CSS 发布以来，我一直在使用它，到目前为止，看到它在过去几年中的成长以及人们用它制作的一些巧妙的东西，我感到非常印象深刻。

总的来说，我对它非常满意，甚至购买了Tailwind UI的许可证，以便更快地使用它进行开发。然而，有时我还是会感到有些沮丧，所以我决定重新构建Ruby 日历项目的前端，看看能不能找出我的烦恼，这应该会很有趣。

我喜欢 Tailwind CSS 的原因

• 文档！说真的，Adam Wathan 做得太棒了。我经常想看看怎么用纯 CSS 做点什么，就参考他们的文档。
• 响应式实用变体非常酷。能够通过lg:在类名前使用 CSS 类名，将 CSS 类应用于大屏幕，真是太棒了！
• 在我的常规 CSS 中使用@apply。感觉这是一种非常简洁的 CSS 编写方式，我非常喜欢它。
• 减少在 CSS 和 HTML 文件之间切换的次数。我之前从未意识到整天在不同文件类型之间切换会给我带来多大的认知负担。现在只需查看一个文件就能处理所有工作，这帮助我更容易进入那种极致的“高度专注”状态。
• 我可以复制粘贴这些示例（它们在我的项目中看起来一样），这节省了大量时间。感觉我不用费太多力气就能快速地为一个项目拼凑出一个前端 MVP。

我不喜欢的

• 预检。我一直觉得它非常繁琐，这可能是因为我以前经常使用normalize.css。为语义化的 HTML 设置基础样式感觉很繁琐。
• JavaScript 依赖。我之前在 Tailwind V1 上有一个项目，用的是 React，后来升级到了 V2。可惜的是，我的库已经过时了，升级过程比我预想的要难得多。最后，我深入研究了 JavaScript 代码，试图找出 CSS 无法正常工作的原因。这让我感觉效率极低。
• 其他开发人员的使用方式不一致。我选了几个使用 Tailwind 的项目，花了很长时间才熟悉代码库。在一个项目中，我感觉其他开发人员好像把所有类都用了一遍，这让我很难找到“快乐的开发者”的感觉。
• CSS 清除。我以前也遇到过类似的问题，设置了清除功能后，移动了一些文件，结果却发现在生产环境中悄悄损坏了几个页面。我觉得更好的 CI 工具可以解决这个问题，但我还是觉得最好从一开始就避免这种风险。
• 保持视觉一致性。我最讨厌用尽所有可用的尺寸和颜色变体，我需要限制一下，以免做出不一致的怪物。

用 vanilla-er CSS 替换它

我的计划是在一个周末内删除 Tailwind，使用混合normalize.css、CSS 变量和混合，然后使用 PostCSS 将所有内容合并到单个 CSS 文件中。

我已经开始使用 来转换我的 CSS，使其符合BEM规范@apply，所以我能够将清理后的 CSS 拆分成更小的文件。然后，我仔细检查了一下，将所有用到的内容（例如间距、字体和颜色）都移到了 CSS 变量中。

为什么使用 vanilla-er CSS？

我希望尽可能接近简单的原生 CSS，因为我之前参与的一个项目大约五年没修改过样式了，然后当我编辑styles.css文件时……它就完全改变了我的预期。这真是一次“哦？你看那个！”式的体验。

显然，我确实喜欢一些低接触工具来帮助减少重复。但我的目标是，五年后，代码库仍然易于上手。我认为最好的方法是尽可能保持简洁。

命名 CSS 变量

命名真难！字体和间距我最终沿用了 Tailwind 常用的按比例编号的方法。

/* variables/fonts.css */

:root {
  --fonts-serif: ui-sans-serif, system-ui, -apple-system, BlinkMacSystemFont,
    'Segoe UI', Roboto, 'Helvetica Neue', Arial, 'Noto Sans', sans-serif,
    'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol', 'Noto Color Emoji';

  --font-size-1: 0.75rem;
  --font-size-2: 0.875rem;
  --font-size-3: 1rem;
  --font-size-4: 1.125rem;
  --font-size-5: 1.25rem;
  --font-size-6: 1.5rem;
  --font-size-7: 1.875rem;
}

/* variables/spacing.css */

:root {
  --spacing-1: 0.25rem;
  --spacing-2: 0.5rem;
  --spacing-3: 0.75rem;
  --spacing-4: 1rem;
  --spacing-5: 1.25rem;
  --spacing-6: 1.5rem;
}

命名颜色

给颜色命名稍微难了点。我从来就不喜欢把一个变量命名为“蓝色”，然后把它的颜色变成蓝色。原因往往是，以后“蓝色”可能就不是蓝色了，这会让事情变得很混乱。

相反，我复制了Bootstrap的“主要”、“次要”和“第三”颜色的方法，但是我明确命名了变量以暗示该颜色旨在用作背景或文本。

/* variables/colours.css */

:root {
  --background-primary: #3c2aaa;
  --background-secondary: #1d2938;
  --background-secondary-lightest: #3f4a5b;
  --background-secondary-light: #232c39;
  --background-secondary-dark: #0f192c;
  --background-tertiary: #d0d5dc;
  --background-tertiary-light: #ffffff;

  --text-primary: #f9fafb;
  --text-primary-darker: #a1a1ab;

  --link-primary: #c5d1ff;

  --border-primary: #273241;
}

我确实也添加了这些颜色的*-light变*-dark体（用于悬停等），但我确实想回来改进我选择的后缀。

理想情况下，我希望实现一个能让其他开发者大声说出“这太明显了，我知道它到底是干什么用的”的变量名。如果有人有什么想法，请告诉我 :)

媒体查询

我想要一种方法来预先定义构建响应式设计时使用的常见屏幕尺寸。

为了解决这个问题，我使用了postcss-preset-env，它允许我定义一个名称为--viewport-lg、值为 的“custom-media” (min-width: 1024px)。由于postcss-preset-env它还支持嵌套 CSS，这使得 CSS 的可读性更高。

/* components/footer.css */

.footer {
  padding: var(--spacing-4);
  padding-bottom: var(--spacing-6);
  text-align: center;

  @media (--viewport-lg) {
    text-align: left;
    grid-template-columns: repeat(2, minmax(0, 1fr));
  }
}

Mixins

很快，我确实感觉到我在重复 CSS 并且将实用程序类与我的 HTML 中的语义命名类混合在一起。

但是，我发现解决方案是通过postcss-mixins使用 mixins 。

/* mixins/list-inline.css */

@define-mixin list-inline {
  list-style: none;
  margin-left: calc(var(--spacing-2) * -1);
  margin-right: calc(var(--spacing-2) * -1);
  padding: 0;

  > li {
    display: inline-block;
    padding: 0 var(--spacing-2);
  }
}

/* components/navbar.css */

/**
 * @markup
 *  <ul class="navbar__links">
 *    <li><a href="/groups">All Groups</a></li>
 *    <li><a href="/add-event">Add Event</a></li>
 *  </ul>
 */
.navbar__links {
  @mixin list-inline;
  margin-top: 0;
  margin-bottom: 0;
  display: none;

  @media (--viewport-md) {
    display: block;
    margin-left: auto;
  }
}

这使得我能够使用包含常见 CSS 代码片段的语义化类名，同时还能根据需要进行覆盖。它还让我能够以编程方式从 CSS 文件中的注释生成样式指南，这让我非常兴奋。

更轻松的导入

随着项目的发展，我发现我可以通过postcss-import-ext-glob来全局导入文件，这使得我的index.css文件更易于维护：

/* index.css */

@import-glob "variables/*.css";

/* External Libraries imported from node_modules */
@import-glob 'normalize.css';

@import-glob "base/*.css";
@import-glob "components/*.css";
@import-glob "utilities/*.css";

最后的想法

总的来说，我对这种 CSS 和 HTML 的整合方式非常满意。我可以查看一段 HTML 代码，了解其中用到的 CSS 类，并且确切地知道需要修改哪些文件才能修改它们。因此，我感觉自己对编写的 CSS 非常掌控。

在审查我的新 HTML 和 CSS 代码时，我非常高兴不再需要盯着一整面 CSS 类名。此外，如果我想修改颜色、间距或字体，我确信无需修改大量文件就能看到理想的视觉效果。我只需打开variables/文件夹，然后打开相应命名的文件，只需编辑几行 CSS 代码即可。

我还发现生成的 CSS 的最终大小与以前大致相同，所以我对此非常满意。

我确实开始意识到 Tailwind 在我设计原型时为我节省了多少时间（以及它如何让我更多地以组件的思维方式思考），但我认为它也是一个非常锋利的工具，需要很多纪律才能在项目中有效地使用。

最后，我想我仍然很乐意从事基于 Tailwind 的项目。不过，我更有信心地说：“如果我们愿意，我们可以直接使用 CSS 变量和 Mixins。”