从自身开发体验谈谈Tailwind CSS
前言
TailWind CSS 是最近两年比较火的一个原子类CSS框架,截止目前在GitHub的Star达到了接近60k,在npm上每周的下载量也超过了3600k。
原子类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-[32px]的类名,这种方式,对于其他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,不过目前还是收费的。也提供了一些免费的常用组件。
比如,像常用的网站头部:
这样,就可以省去自己手写,个人还是觉得比较有用的。
以上几点就是自己在开发过程中的主要体验了,下面自己将结合开发体验,归纳一下TailWind CSS的优缺点。
优点
-
提供了大量类名,减少了写style样式代码。
-
提供断点类名,对做响应式开发有很大便利,一套代码实现。
-
为那些css能力不强的同学或者初学者甚至非前端同学提供了便利。
-
打包的css体积很小,未使用的类名不会打包输出。
-
提供了自定义类名配置,扩展了使用场景。
-
提供了一些基本的组件,对我这种拿来主义比较利好。
缺点
-
增加了学习成本,前期需要记大量的类名。
-
标签里面写大量的类名,显得丑陋,不符合css规则。
-
后期修改以及维护比较麻烦。
-
大量写类名,会降低开发者css能力。
-
封装业务组件带来的样式穿透问题。
-
需要搭配UI规范,否则多人开发不好维护。
总结
移动端h5的话,像自己公司是没有依赖任何第三方库的,自己写一些基本的组件也比较简单,没有需要使用TailWind CSS的必要。
管理后台,一般使用Antd Design或者Element UI就够了,涉及到的样式本身就比较少,而且管理后台一般也很少需要做很好的响应式适配,一般对页面样式要求不高,像我们公司,管理后台甚至都没有设计稿,直接对着原型就开始了。
TailWind CSS目前的使用场景,个人觉得还是在做响应式网站方面,特别像是官网这种。TailWind CSS本身就是做响应式的,然后一般的官网页面都比较简单,不会有太多的类名造成维护问题。如果公司有很好的UI规范,做官网真的会非常爽。
转载自:https://juejin.cn/post/7131653616623943716