如何评价CSS框架TailwindCSS？
本人的 CSS 方案常用 TailwindCSS，在这里谈一点感受，并对一些常见的问题解答一下 TailwindCSS 因为一个 class 代表一个 CSS 属性这种原子化 CSS (Atomic CSS)，这种细粒度的 CSS 方案备受争议。 这里把 CSS 样式的方案分为四种粒度 越往下走，颗粒度越来越大，约束性变高，自由性不足。而 TailwindCSS 位于第二层。 Tailwindcss 为啥受欢迎，在我看来无非是更好用的原子化的CSS。在国外如火如荼，但是在国内论坛上争议很大，前几天在我的博客上写了一篇关于 Tailwindcss 的文章，但是底下评论很多了各种问题，于是再总结一下 大部分人的想法应该是这样的: 仅仅对于 text-center 而言，虽然提供了些许方便，但是不足以拉开差距。 如果说它仅仅是简单的原子化 CSS，好用却不亮眼。但是它却不仅仅止于此。 或许一个 text-center 不足以使你觉得提供了多大的方便性，但对于一个三等分的 Grid 属性来说，一个 grid-cols-3 和 shadow 绝对方便 或者你还能记得 box-shadow 各个位置的参数吗？ 我敢保证看这篇文章的人至少有 93% 说不上来 在 tailwind 中，直接用 .shadow 简单方便 text-lg，一个较大字体，如果设置行内样式，肯定有诸多麻烦的事: 我想设计一个较大的字体，那我应该设计多大尺寸、使用什么单位 同样还有: 新人总容易弄出一种大红大绿的新人风格网页，有了一些约束就很难出现这种很糟糕的色彩控制 另外，有了 text-lg 此类，一个页面上就不会出现几十种参差不同的字体大小 先来看一个在工作中会遇到的响应式布局问题，这也是我上一次在头条面试时的一道题目 通过 grid 布局很容易实现，但未免繁琐 那使用 tailwind 呢? 只要一行，就问你高效不高效 把修饰符，如各种伪类、暗黑模式、响应式设计至于前缀的设计简直深得我心 很遗憾，不能。不过虽然你无法摆脱手写 CSS，但是你基本上也写不了几行，说以下几种很常用的情况 当父级元素鼠标悬浮时的，子级元素的样式控制 这个问题就仁者见仁智者见智了，在 Vue 的 template 语法中也经常出现此类问题，很多人会对一些命名上的约定，特别是自己不太喜欢的约定天然排斥，这也无可厚非。 我在初期确实会一边开发网页，一边瞅着文档全局搜索: TailwindCSS 属性查找，现在借助浏览器插件及熟能生巧的经验已经不太需要翻文档了 初期经常花时间翻文档而不手写 CSS，而其中的原因不外乎两个: 过了多久就会觉得: 嗯，真香 因为他确实比较方便，算是解决了痛点。而且 Star 也和功能复杂度无关 使用 Gihub Star 数和 npm 周下载量来表明一个库的受欢迎程度，那么你会发现有的库只有几十行，下载量比 React/Vue/Angular 加起来都要多 我算是 TailwindCSS 中度使用者吧，目前还没有后期维护困难方面的困惑。甚至可以说，维护比以前的方案还要容易 至于调试，可轻松使用 chrome devtools，还是可以一眼望到底的，而且没有以前各种 class 存在属性重复覆盖，造成调试困难，从下图可看出 tailwindcss 调试一目了然 即使实在有过多的 CSS Class，也可以通过 Computed 面板中的小箭头跳转过去找到相对应的 class Facebook 经过重构后 CSS 体积已经从 413Kb 减至 74Kb。 gzip 的核心是 Deflate，而它使用了 LZ77 算法与 Huffman 编码来压缩文件，重复度越高的文件可压缩的空间就越大。 即使 HTML 因为类名过多造成体积增大，由于 class 高度相似，gzip 也将会得到一个很大的压缩比例。 tailwind 使用了 purgecss 删除无用的 class，但有时候会吧有用的 class 也给删掉。道理也很简单，它并不能动态执行代码，你计算后的 class 他不认识就给你删了 比如: 所以我强烈推荐使用 classnames 上面这段在文档里有描述: 如何正确书写能够被 purgecss 识别的样式 以下 red 与 blue 两个样式哪个会生效？无法确定。 class 在样式表中的顺序决定，而非在 class 中的先后顺序。这使得通过 className 扩展样式时遭遇问题，示例如下 再来谈几个实践的点 此时样式由大量的 tailwind 及少量的 styled-jsx组成。需要注意此时需要搭配 styled-jsx 的 postcss 插件使用 - END -