真的有人喜欢用 tailwind 么

2025 年，如果你还在手写 css 或者 sass ，就是个纯 xb

@lizy0329 我就一个问题，在 devtools 中找到一个 element 节点，怎么快速定位到对应的代码位置？

@wednesdayco #102
tailwind 流行的原因还有一点就是恰逢前端组件框架兴起，组件框架发展同时迭代了工具链。
就比如 vue ，安装 vite-plugin-vue-inspector 插件（如果用的 Nuxt ，内置 Devtools 自带），使用定位元素功能可以直接在 vscode 中跳转到对应源码位置。
不过用 utility class 时，元素的 class 本身就很少会很相似，比如开头单词、整体长短等，比较容易对应上。

> 看着满屏的样式写在 html 上就头疼
对于重复的、长的 class 属性，你完全可以抽离出来放到 css 类里并使用 apply ，就如同#51 Pipecraft 截图那样，或者放到 js 里作为字符串，对于 vue 单文件组件或者 jsx 来说就是前后脚的事。
此外，utility class 与 css 不是互斥的，只是 css 的特化，如果你不喜欢它写出来的样子，你完全可以很方便地转换成更原始的方式，例如用各种 tailwind to css 工具或者 unocss 的 compile mode 转换成 css 。
不过很少人这么做，因为 tailwind 的主要优点之一就是非常适合快速原型开发，后面我举个例子你就懂了。

> 点开 devtools element 想找个节点都难找
我将工具方式写在 #103 了，不过一般用这个工具是因为定位元素源码本身就是一个独立需求，而不是受用不用 utility class 影响。（以及以防你说的是在 devtools 自身面板里找不到对应元素，不是定位元素点一下就找到了嘛，除非你嵌套了 N 层元素还不加间距。）
此外用 tailwind 都是直接在源码上修改并看效果的，很少会去 devtools 里看元素，一般都是因为 UI 组件库增加了额外嵌套元素导致 flex grid 等失效需要 debug ，或者不熟悉的属性快速尝试所有可能选项时才会检视元素，所以不太清楚为什么这一点成为了阻止你使用 utility class 的原因。

> 生僻一点的样式就还得去翻下文档
熟悉了就好了，很少会用到的是要查，但生僻的 css 属性不也是该查还得查，不知道你在哪里查 css 属性，但至少和 MDN 比，tailwind 的文档还是更好查的。

我举一个极端的例子，假设一个父元素 div 有 4 个子元素 div 。
然后按照以下步骤修改：
1. 父元素 grid 布局分 10 列，子元素分别占 2 、2 、3 、3 列，
2. 对于子元素，占 2 列和占 3 列的，把各自其中一个元素设置为背景绿色，另一个元素背景红色。
3. 对占 2 列的绿色背景元素，设置鼠标悬浮时背景变为白色，红色背景的悬浮时变为黑色。占 3 列的反过来。
4. 给占 3 列绿色背景的元素添加边框。
5. 删除红色背景元素的悬浮样式。
6. 删除占 2 列的元素并剔除无效样式。
过程上：
- 如果是 utility class ，我所有的更改都在对应元素上完成，批量修改时基本上用一下垂直选择或者 ctrl+D 即可，不用考虑给类起名，不用考虑拆分选择器，不用担心变更样式时会影响到外部元素，只需要在当前行查找对应类名并修改，不用考虑类的前后/层级作用关系以及选择器优先级。
- 如果是原生 css 或各种预处理器，假设你还想尽可能地降低重复内容，你每一步可能都要考虑如何写类/选择器，各自包含哪些属性，在修改时你可能需要在 html 和 css 中反复检索来避免影响到其它元素，在这个过程中你可能要起很多次类名/选择器才能适配每一个变化
结果上：
- utility class 没有样式文件，就是类列表可能比较长。
- 原生 css/预处理器，最后对 css 代码精简，最直观的结果可能有两种：
1. 每个元素对应一个类，类名失去复用性，每个类都包含很多属性，
2. 每个选择器只包含一个属性，需要对应属性的元素复用相应的选择器。
前者相当于 apply 写法，但要赘余很多。
后者就是 utility class 。

@UnluckyNinja 首先感谢你这么认真的回答，不过我也写 tailwind ，只不过大多数时候写的时候感觉不方便。
你也举了一些例子，我也学到了。
不过我还是有问题
1. 我在走查页面的时候发现一个样式错位，那么我需要去找到这个 element 对应在代码中的文件，通常使用 scss 之类的我可以通过类名全局搜到对应的文件，但 tailwind 我不知道怎么做，只能去找到对应的 component 再去找对应的文件，操作路径长得多。
2. 生僻一点的要翻文档，我需要先去 mdn 翻然后再去 tailwind 翻吧 hhhhh
3. 你的同步改到浏览器中需要框架支持吧，如果某些原因导致 hot reload 失效，或者不能用*真有*咋办 hhhh 。

总之我也用这个，但就是用的没那么爽。你说传统 css 需要考虑各种类名，但其实使用 scope/module 的话，都是原始的几个类型来来回回使用不那么需要考虑叫啥。

@wednesdayco 我猜你应该是不熟悉 chrome devtool css layout computed 几个页面吧
前面有人说 css 语义派 和原子派的取舍
如果你用 scss css 那你的操作路径感觉也挺长的 而且页面来回切换 效率肯定不高
和 tw 优势比起来 确实效率低啊

@beidounanxizi 这跟 layout computed 页面有啥关系？我说的这些点力那里涉及到这俩功能？
页面为啥要来回切换，做开发两个显示器都没有？

》但 tailwind 我不知道怎么做，只能去找到对应的 component 再去找对应的文件，操作路径长得多。

走查页面 你用 tw 自然就用 css 面板 debug


》 常使用 scss 之类的我可以通过类名全局搜到对应的文件，

那可以用 code inspect plugin 可以跳转

另外 你的 scss 又不一定你最后起作用的样式


css 样式和代码 放在 2 个文件 不难受吗

看你 这么说吧 chrome devtool css 几个 tab 你都没完全熟悉

最终决定布局的又不是 scss ， 直接看 layout computed 直接改不行？

@wednesdayco #105
1. 如果你有在用 vite ，对于 vue 就像#103 所说的用 vite-plugin-vue-inspector/unplugin-vue-inspector （这俩是同一个），如果是 react 可以用 https://github.com/hunghg255/vite-plugin-reactjs-inspector ，svelte https://github.com/sveltejs/vite-plugin-svelte/tree/main/packages/vite-plugin-svelte-inspector ，以此类推。

如果你没有用 vite ，但是有用 vue/react 等，可以用相关 devtools 查看组件树，然后用定位功能定位组件，相比上面的方法，多了几次交互，精度到文件。

如果你没有用 ui 框架，但你页面内容和文件组织结构比较相似，那按目录直接找应该不是太大问题。如果文件很乱，还看不出单独组件，或者你觉得麻烦，那估计只能是搜类了。就像你用 scss 时搜单个类，tailwind 你可以直接搜整个 class 属性，本地 vscode 检索很快的，记得把 node_modules 等目录排除。

2. 生僻感觉大致分两种情况，

第一种你不知道想要的样式需要什么类名/属性，这种可以直接去 tailwind 上搜索关键词就行了，如果 tailwind 不能满足再去 mdn ，例如自定义的 grid 排列方式，这种我知道 tailwind 没有，也就知道该去哪查文档了。

第二种你不知道 tailwind 类名如何影响元素（这种装了 vscode 插件可以直接悬浮显示 css 属性，或者直接去浏览器看元素样式也不是不行），也是先去 tailwind 看属性看效果样例，如果不了解属性值/没有例子，才是去 mdn 查属性值。

一般都是先查 tailwind 再查 mdn ，等大致了解了 tailwind 能做什么不能做什么，也就不用跑两边了。

3. 关于 hot reload ，最差情况是你需要刷新网页来刷新状态，但多数情况 vite 及 ui 插框架件已经帮你处理好了，很少会遇到不能用的情况。不过和查找元素的一样，不是决定用不用 tailwind 的因素，其本身就是对前端开发体验的极大增强。

总而言之，能直接用 utility class 省事太多了，个人习惯是可以适应和改变的，但 utility class 减少的工作量是实打实的，所以才会流行。