听说 Tailwind 因为 AI 被卖给 Shopify。但说实话至少一年前就已经能看出苗头。如今这套样式框架进入了企业的掌控之下——有好处也有坏处。现在该看看下一步了。AI 已经能免费生成组件靠卖组件维持未来显然不容易何况 Nuxt UI 和 Daisy UI 早就存在。AI 甚至能直接写出 JavaScript 和 CSS。因此未来的开发重点不该是让它设计一个网页然后每改一点外观就消耗数百万个 token更值得想的是我们怎样掌控设计所以我想问的不是“CSS 的未来是什么”。CSS 本身一直在进步只是速度慢得像蜗牛。真正的问题更像是“Tailwind 之后是什么”就像十年前大家问“Bootstrap 之后是什么”一样。一个很香的 AI 平台GPT-5.6 低倍率且不降智 和 Claude Code 4.8 只要 0.25倍率包含 image-2生图。重点是 首字请求都在 5s 内。入口https://ai.aiyuhub.com即时生成样式CSS-in-JSTailwind CSS 用在静态网页上时有个大家熟悉的限制你只能使用框架提供的样式。比如你想要一个介于两档之间的颜色bg-red-550就得自己写样式可一旦这么做使用框架原本图的那份方便也就打了折扣。几年前Windi CSS 和 Twind 想解决的正是这个问题开发者不必被框架预设的样式绑住。你写下类名JavaScript 引擎就即时生成对应样式。后来 Tailwind CSS 也注意到了这个方向并作出调整。Windi CSS 和 Twind 的存在感逐渐减弱最终被各自作者放弃。与此同时功能更丰富的方案也出现了UnoCSS 和 Master CSS。它们同样围绕即时生成样式展开却各有做法。另一边Open Props 只靠 CSS 变量提供了类似 Tailwind CSS 的能力。Vanilla Extract、StyleX 和 Panda 则与 JavaScript 结合得更紧密让开发者以更可控的方式编写样式这类方案可以归为“零运行时引擎”。选择突然变得这么多。到底谁更像下一站UnoCSSUnoCSS 会检测你使用了哪些类再即时生成对应的样式。换句话说bg-red-550可以成为一个有效的类名并在组件用到它时生效。在那之前这条样式根本不存在。而且它追求的就是快速生成。当然UnoCSS 也会用静态规则生成外边距、边框等预设类。但它更有意思的地方是动态规则的能力。代价是当你需要用正则表达式构造许多规则时配置可能越来越难读。我很难想象一次读完十多条这样的规则会有多轻松希望后续版本能改善这一点。rules:[// Create margins for any digit, from 1 to infinity.[/^m-(\d)$/,([,d])({margin:${d/4}rem})],],variants:[// support hover: for all rules{match:ss.startsWith(hover:)?s.slice(6):null,selector:s${s}:hover,},]UnoCSS 还给了开发者更多控制 HTML 写法的空间。你可以创建工具类也可以直接用 HTML 属性声明规则。这种语法未必符合所有人的审美却能减少class属性里越堆越长的内容。divm-2roundedtext-teal-400buttonbgblue-400 hover:blue-500 dark:blue-500 dark:hover:blue-600textsm whitefontmono lightpy-2 x-4border2 rounded blue-200Button/button/divMaster CSSMaster CSS 和 UnoCSS 一样也能即时生成样式但它想让样式表达得更紧凑。它要解决的是 Tailwind CSS 从一开始就存在的“类名堆积”问题。UnoCSS 提供了类似 Tailwind 的类名写法Master CSS 则没有把你固定在某套词典里而是让语法更贴近 CSS 属性同时尽量保持可读、简短、可控。这让我觉得它更进一步但也意味着你得比使用 Tailwind 时更多地思考 CSS 本身。有个例子我很喜欢它用一套不难理解的特殊语法让类名写法符合 DRY也就是“不要重复自己”。整个例子都不依赖 Tailwind。// Beforeaclassanimation-name:fade animation-duration:1s animation-timing-function:ease transition-property:opacity transition-duration:.3s margin-top:1rem margin-bottom:1rem margin-right:2rem margin-left:2.5remThis is a button with a lot of CSS/a// Afteraclassfade|1s|ease ~opacity|.3s m:16|32|16|40This is a button with 80% less code/aMaster CSS 正在迈向 2.0。写下这些文字时它已经有了第 88 个候选发布版本接下来就看正式发布前还能找出哪些小问题了。Open Props再看另一端Open Props 不需要 JavaScript。它利用 CSS 变量提供了一套与 Tailwind CSS 有相似之处的样式能力。它的想法很直接既然 Tailwind 需要 JavaScript 库处理 CSSUnoCSS 和 Master CSS 又依赖即时生成样式的引擎为什么不直接用 CSS 变量解决问题这样无需额外加入构建步骤原生 HTML 页面也能用运行时没有额外负担。当然这也意味着你得回到 CSS 样式表为每个想要的“模块”定义样式。不过在 AI 已经能帮你生成组件的情况下对产出结果做些细小调整或许不算太麻烦。另一个区别是Open Props 没有 UnoCSS 和 Master CSS 那样的即时生成能力。如果现成的尺寸或颜色不是你想要的你得手动定义一个局部自定义属性或者自己写一个类。button.blue{color:var(--blue-6);background-color:var(--blue-0);border:1px solidvar(--blue-1);text-shadow:0 1px 0var(--blue-2);:hover{background-color:var(--blue-1);}}在这些替代方案里我觉得 Open Props 最有前景。但也别把它说得太神奇粗看之下它有点像一套借助 CSS 变量实现的“OpenTailwind”。即使你觉得这像是在重新造轮子它仍有一个实用之处你不必把 Open Props 的所有内容都装进项目只下载、使用需要的部分就行。零运行时引擎现在我们彻底走进 JavaScript 的地盘。如果前端本来就用 JavaScript 写为什么不连 CSS 也一起用它写这里说的不是把一段 CSS 塞进 JavaScript再从 HTML 中引用而是直接用 JavaScript 编写样式。借助这类框架定义好样式后再把它应用到目标元素上。在 JavaScript或者带有类型安全能力的 TypeScript 中这套做法大致围绕下面的语法展开// Import the styling engineimport{style}fromjavascript-as-style/style// Create the style with objects equivalent to CSSexportconstcontainerstyle({padding:10,border:{left:{width:1,color:red,style:solid,}}});// Apply the style into the HTML elementdocument.write(section class${container} ... /section);这类工作流中比较知名的三个框架是 Vanilla Extract、StyleX 和 Panda。它们的大致方式相近你在 JavaScript 中编写样式可以直接写在代码里也可以单独放进文件再应用到 HTML 元素上。差别主要在各自如何组织这件事Vanilla Extract更像“用 JavaScript 写 CSS”传统的样式规则可以近乎一一对应地写成对象。想直接控制 CSS 的人可能会喜欢它。StyleX强调确定性用来处理样式层层叠加、相互覆盖的问题也适合限定一组可用的值或颜色。它很适合团队协作由 Meta 创建也就不难理解了。Panda有点像“用 JavaScript 写 Tailwind CSS”你写的是带有具体值的工具式属性而不是传统 CSS 规则。已经习惯 Tailwind 思路的人可能更容易上手。从代码层面看好处很明显尤其是可以减少那些原本要靠静态检查工具才能发现的手误。但代价也同样明显你会更依赖它们各自的语法和生态。假如项目下个版本想换一种 CSS 策略或者某个框架因为“AI 改变了一切”而停止维护迁移时可能又得从头做一遍。那么CSS 的未来到底是什么老实说在 Tailwind 之后我更愿意押注 CSS 自身继续前进而不是让项目越来越依赖 JavaScript 构建流程。从这个角度看Open Props 可能是最大的受益者。不过论开发时的便利程度我仍觉得 UnoCSS 和 Master CSS 是很自然的下一步选择面对一个 AI 可能 30 秒就写出来的营销网站开发者更需要顺手地控制样式。我对推动 CSS 标准的人最大的不满是他们的速度。一个问题等到被解决时开发者面对的可能已经是另一批新问题修复也因此显得没那么及时了。这种缓慢有原因向后兼容以及需要多方共同讨论、达成共识。桌边坐着 GoogleChromium、AppleSafari、MozillaFirefox和 MicrosoftEdge。想想曾在 15 年前流行的“瀑布流”网格相关标准仍在草案阶段你就能感受到这种速度。我个人认为CSS 工作组CSSWG应该优先解决两个问题类的复用和动态生成。一旦这两件事有了解法大多数涉及前端样式的项目或许就不必再为了样式而依赖 JavaScript。如果能在 HTML 的类名之外复用样式就不需要反复把同一批 CSS 属性复制到不同的类里也不必只为这件事引入 JavaScript。.interactive{/** ... */}.tappable{/** ... */}.btn{/** Import the classes instead of copy-pasting these */use.interactive,.tappable;/** These override the classes */background-color:red;}如果 CSS 自己就能动态生成类那么普通类名覆盖不了的特殊需求也不必靠 JavaScript 处理样式表里也不用塞满只会使用一次的类。style:root{--danger:#ef4444;}/** Allow a variable to be part of the class name */.btn:$color{/** Resolves into --danger */background:var(--$color);}/stylebodybuttonclassbtn:dangerDelete comment/button/body这会省去不少麻烦。开发者可以少花精力在 HTML 与 CSS 之间核对样式是否匹配把注意力放回样式本身。我希望 UnoCSS 和 Master CSS 的核心能力有一天能进入 CSS 这一层而不是一直留在 JavaScript 或构建步骤之后。也许对当前的 CSSWG 成员来说这个要求太高了。但关键在于CSS 能否自己提供足够有力的样式能力如果它始终只是 JavaScript 框架给前端上样式时调用的一门语言而又迟迟跟不上开发需求人们自然会问那为什么不干脆全面投入 JavaScript希望他们不用再花十年才拿出解决办法尽管这完全有可能。说不定我也能用一个简单的 JavaScript 文件先做出具备这些能力的 CSS 框架。至少这会是个向老板申请 100 美元 Claude 额度的好理由——上次我提起这个问题时他们可不愿意为了“给按钮上个色”专门招一名前端开发者。