liy1wen

V1

2022/08/14阅读:22主题:默认主题

从自身开发体验谈谈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端
pc端
手机端折叠
手机端折叠
手机端展开
手机端展开

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

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

优点

  1. 提供了大量类名,减少了写style样式代码。

  2. 提供断点类名,对做响应式开发有很大便利,一套代码实现。

  3. 为那些css能力不强的同学或者初学者甚至非前端同学提供了便利。

  4. 打包的css体积很小,未使用的类名不会打包输出。

  5. 提供了自定义类名配置,扩展了使用场景。

  6. 提供了一些基本的组件,对我这种拿来主义比较利好。

缺点

  1. 增加了学习成本,前期需要记大量的类名。

  2. 标签里面写大量的类名,显得丑陋,不符合css规则。

  3. 后期修改以及维护比较麻烦。

  4. 大量写类名,会降低开发者css能力。

  5. 封装业务组件带来的样式穿透问题。

  6. 需要搭配UI规范,否则多人开发不好维护。

总结

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

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

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

分类:

前端

标签:

JavaScript

作者介绍

liy1wen
V1