缘起
这篇文章是在讨论提出引入 utility-first 类的 css-in-js 框架，一时兴起写了一些对于这种类型框架的想法。
稍微调整一下，再加入新的想法，发到这里。
迷之见解
当时提议引入 windicss 的人有这么几点见解：
- 解决命名焦虑，windicss 让开发者不需要考虑命名
- 利用 JIT 做到动态解析类参数生成 css 的 windicss 出现了，在没 design token 规范的项目都可以很自由地使用任意参数
- 样式逻辑都内聚在一个地方，换句话说就是复制粘贴方便
理由都很好，特别是最后一条让我无法反驳，甚至让自己对 css-in-js 有新的理解。
但我始终不能接受这些理由。
变形了的工具
因为我对设计系统，design token 等概念有所了解。并一直为这些美好的概念不能落地到实际工作场景中而感到苦恼。
Tailwind 让我看到了一个落地方式，框架可以引导使用者对 design token 有一个更为确切的认知。
但引入了动态化，我感受到一个工具的变形。
当然这不是 tailwind 的作品，他只是跟随着社区的变化引入了 JIT，但由此我们可以看到开发者需要什么样的工具。
于我，design token 是一个规则，他是死板的，引入了动态化无疑就是打了自己的脸，工具变形成大家希望的样子。
为什么有 utility-first 的 css
- 设计规范只有极小数公司有在执行
- 大多数设计不懂设计规范和 design token 这些以程序员角度思考的 UI 定义和规则
没有规则就不能做抽象，所以就不要谈 UI 组件化的事情了，这些都是小部分开发能享用的好东西，大多数前端处理业务，都是用开源的组件换个皮做的功能。
- 极小粒度的抽象层次
- 提升了清晰度的 css，大家喜欢吃糖
前端总是被设计牵着鼻子走，每次开发辛苦抽象出来的设计内容，隔几个版本就会被打破。如此循环往复，开发只能被逼地把抽象粒度压到最小，其抽象层次落到了 css 的属性层面上了，也就诞生出了 tailwind 这些 utility-first 的 css 框架。
为什么搞出了 JIT
因为在大多数情况下，设计是不会管开发的抽象的，他们的脑洞依旧还在疯狂生长，打破 design token 更是家常便饭。
没技术的开发，使用 !important，反正层叠样式表，叠就是了。
有技术的开发，得带点技术来摆烂，那就掏出编译器来制定规则化 util 类，来承担更为动态化的需求。
utility-first 的好处
我认为好处有这些点：
- 可自定义样式别名系统
- CSS 样式语法糖
- 归纳与重构工具
关于第三点想着重说一下：
由于抽象粒度拆到极细，工具能在更高维度理解到整个项目的 css 属性使用情况，从而能够让整个项目的 css 限制在一个固有的集合里面，是一种程序化的自动抽象功能。其产出物的复用率达到了极致，而且开发者们还是可以继续写这些重复代码，且使用者没有理解成本，大家都开心，这是我觉得 utility-first 的 css 框架与其他 css 编写方案的最主要不同，也是最显著的特点。
「就算疯狂堆屎山都没关系，产出物都是高效的，真是一款完美的清理机器。」
感谢诞生了 Headless UI
这个概念很好，也是再次证明技术被设计逼疯了，只能抽象出纯逻辑的控件。
最后
技术被设计逼疯可能只是一个说辞，也有可能是我被设计逼疯了才得出这个结论。
功能粒度变得越来越细，越来越精细化分工，可能才适合这个复杂的世界吧。