从自身开发体验谈谈Tailwind CSS

前言

TailWind CSS 是最近两年比较火的一个原子类CSS框架，截止目前在GitHub的Star达到了接近60k，在npm上每周的下载量也超过了3600k。

GitHub

原子类CSS（Atomic/Utility-First CSS）与我们常用的语义化CSS不同的是，框架本身为我们提供了一系列类名来表示对应的CSS规则。当我们想写一个css样式时，我们不再需要给标签一个语义化类名，然后再给类名添加CSS规则，我们只需要给标签一个框架提供的类名就行，最后在编译过程中，会自动生成对应CSS规则，这就是原子类CSS，以及它和我们常用语义化标签的不同。

TailWind CSS和很早之前的Bootstrap比较相似，他们都是给开发者提供了大量css类名，希望用类名代替CSS规则。不过Bootstrap目前几乎已经被市场所淘汰，过去我在公司用Bootstrap+JQuery写响应式网站的时光已经一去不复返了。

那么和Bootstrap类似的TailWind CSS为何走上了和Bootstrap完全相反的道路，越来越火呢？TailWind CSS目前在前端市场的评价包裹不一，评价两极分化严重。这篇文章将以自己最近开发项目过程中使用它的情况，从自身开发体验以及框架自身的优缺点方面来给大家分享一下TailWind CSS的优势以及存在的问题，让大家在打算用这个css框架或者打算学它之前对它有个比较清晰的认知。

使用契机

最近自己在重做公司的官网，主要是用ssr+midway.js这一套做服务端渲染。但是一般做官网，就逃不了要做响应式。就当自己在想用什么方式去实现响应式更好的时候，前不久刚看到的比较流行的TailWind CSS突然进入了自己的脑海，虽然网上有很多对这个框架负面评价，自己还是打算用公司的官网去试试，踩踩坑。就这样，安装、引入、配置一键三连搞起...

开发体验

前期类名不熟悉带来的低效

开始开发的时候，最大的麻烦就是大量的类名，自己根本是记不住，所以经常是一个简单的css样式，比如width：100%，自己往往就是先去文档里面找width的菜单，然后再到width的类名里面找到表示width：100%的类名，虽然官方提供了智能的类名提示插件Tailwind CSS IntelliSense，但是前期由于对类名不熟悉的原因，还是存在了大量查找的工作量。有点像我们在使用UI框架的时候，比如我们需要实现一个面包屑，我们需要在对应UI框架里面找到面包屑的代码然后复制，不同的是，TailWind CSS寻找类名的过程更加麻烦，而且往往一个小小的组件需要使用的类名都是几十个上百个，前期这样造成的工作量其实还是蛮大的。

类名支持任意值带来的便捷

随着项目的进行，自己在不断使用类名的过程中，对类名也是越来越熟悉，搭配插件提示，代码效率也是直线向上，大部分情况下已经不需要查找类名就能直接写出来了。但是这里也出现了一个问题，就是框架提供的这些类名已经无法满足开发需求了，比如页面的一个二级标题是32px的，但是字体大小的类名里面是没有32px的，这个时候我们只能自己通过语义化类名去单独写样式了。不过，TailWind CSS提供了任意值的类名规则，我们想实现32px的字体大小，只需要加入text-[14px]的类名，这种方式，对于其他css属性的任意值也是同样适用，这样就大大增加了开发的灵活性。

完善的设计规范结合自定义配置让我们脱离TailWind CSS开发

我们公司的UI是有明确的一些设计规范的，比如字体的大小颜色，按钮的大小颜色、交互效果以及不同尺寸的样式等等。这样意味着我们很多的类名尺寸或者颜色等都不需要使用TailWind CSS提供的，而是使用公司设计规范的这些尺寸和颜色。通过上面说到的如text-[14px]这种任意值的方式可以实现，但是页面太多，这样写不好维护和管理，不过tailwind.config.js文件可以让我们在项目的根目录中查找一个可选文件，可以在其中定义任何自定义项。

// tailwind.config.js 官网实例配置
module.exports = {
  content: ['./src/**/*.{html,js}'],
  theme: {
    colors: {
      'blue': '#1fb6ff',
      'purple': '#7e5bef',
      'pink': '#ff49db',
      'orange': '#ff7849',
      'green': '#13ce66',
      'yellow': '#ffc82c',
      'gray-dark': '#273444',
      'gray': '#8492a6',
      'gray-light': '#d3dce6',
    },
    fontFamily: {
      sans: ['Graphik', 'sans-serif'],
      serif: ['Merriweather', 'serif'],
    },
    extend: {
      spacing: {
        '8xl': '96rem',
        '9xl': '128rem',
      },
      borderRadius: {
        '4xl': '2rem',
      }
    }
  },
}
复制代码

在文件theme里面，我们可以自定义任意我们需要用到的颜色、字体、字体大小、间距、圆角等等，在开发过程中，我就将UI提供的设计规范对应的这些属性尺寸颜色全部写入了tailwind.config.js里面，这样在开发过程中再也不用去查文档，使用TailWind CSS提供的类名了，全部使用这里面自己规定的自定义类名。开发效率蹭蹭往上升。

@apply对类名的抽离以及复用

由于需要做响应式，所以一个类名需要根据断点写多种去适应不同的尺寸。这样，一个标签里面难免会存在几十个类名，大大影响了代码体验，甚至和直接在style里面写样式没什么区别了，而且很多标签是可以共用一部分样式的。好在TailWind CSS提供了@layer指令，将任何现有的类名内联到自己的自定义CSS中。这点有点像css的mixin（混入）。

.select2-dropdown {
  @apply rounded-b-lg shadow-md text-lg font-bold text-gray-900;
}
复制代码

我们只需要给标签添加select2-dropdown类名，他就表示下面包含的五个类名，这样我们就做到了减少标签里类名数量，而且还可以做到复用。不过自己还是会觉得这样没有解决大量类名造成的困扰。

设计稿调整以及后期维护带来的巨大不便

项目过程中，难免会出现设计稿的调整，这时候，就需要我们修改标签类名了。然而这个时候，我才算碰到TailWind CSS带来的最麻烦的地方。比如说，设计告诉我们，有一块的内边距由12px改为20px，那我就去找这个元素，然后我发现这个元素有20多个类名，我眼睛瞟了几圈终于发现表示内边距12px的类名，正当我高兴之时，我才发现这个类名是xl断点下的，而我需要修改的是sm断点下的，于是我又重新去找sm断点下内边距12px的类名....

提供了UI框架以及基础组件

TailWind CSS虽然是一个css框架，他也有一个UI框架tailwindui，不过目前还是收费的。也提供了一些免费的常用组件。

比如，像常用的网站头部：

pc端

手机端折叠

手机端展开

这样，就可以省去自己手写，个人还是觉得比较有用的。

以上几点就是自己在开发过程中的主要体验了，下面自己将结合开发体验，归纳一下TailWind CSS的优缺点。

优点

提供了大量类名，减少了写style样式代码。
提供断点类名，对做响应式开发有很大便利，一套代码实现。
为那些css能力不强的同学或者初学者甚至非前端同学提供了便利。
打包的css体积很小，未使用的类名不会打包输出。
提供了自定义类名配置，扩展了使用场景。
提供了一些基本的组件，对我这种拿来主义比较利好。

缺点

增加了学习成本，前期需要记大量的类名。
标签里面写大量的类名，显得丑陋，不符合css规则。
后期修改以及维护比较麻烦。
大量写类名，会降低开发者css能力。
封装业务组件带来的样式穿透问题。
需要搭配UI规范，否则多人开发不好维护。

总结

移动端h5的话，像自己公司是没有依赖任何第三方库的，自己写一些基本的组件也比较简单，没有需要使用TailWind CSS的必要。

管理后台，一般使用Antd Design或者Element UI就够了，涉及到的样式本身就比较少，而且管理后台一般也很少需要做很好的响应式适配，一般对页面样式要求不高，像我们公司，管理后台甚至都没有设计稿，直接对着原型就开始了。

TailWind CSS目前的使用场景，个人觉得还是在做响应式网站方面，特别像是官网这种。TailWind CSS本身就是做响应式的，然后一般的官网页面都比较简单，不会有太多的类名造成维护问题。如果公司有很好的UI规范，做官网真的会非常爽。