这是未来的趋势所向，如是我行。

注意：原文发表于 2017-9-6，随着框架不断演进，部分内容可能已不适用。

CSS 日渐惹人憎恶。

究其原因颇多，归根结底，皆因 CSS 给人的感觉总是飘渺迷蒙、变幻莫测。

譬如微调某个样式后，却出乎意料地殃及一些看似毫无瓜葛的布局，尤其是准备部署之时。

这类经验如果你从未体会过的话，你要么是不明就里的新手，要么是登峰造极的高人。

故此 JavaScript 社区又开始撸起袖子着手炮制，只消数载，各色各样的 CSS 库宛如雨后春笋不断涌现，它们统称为 CSS-in-JS。

然而 CSS 最棘手的问题也许并不需要 CSS-in-JS 亦可解决，对此你可能还不知情。

倘若果真如此，那么编写 CSS 将是一种惬意的享受，而非痛苦的忍受，此外，CSS-in-JS 也会产生新的问题要去解决，未免有点旁生枝节。

本文并非要和 CSS-in-JS 针锋相对，也不否定社区所做的努力，它在 JS 生态中如此活跃，且每周都有新的想法出现。

其实我目的是想介绍一种让人更加愉快的替代方案 —— 它就是带有真正 CSS 的单文件组件！

CSS 最大的问题

CSS 中的一切都是全局的，正因如此，为某个标记上编写的样式，可能会使另一个标记受到牵连。

也正因如此，开发者经常借助于各种命名空间的约定（而非“规则”，因为难以实施），但此法只会徒增 RSI 的风险。

如果你置身于团队之中，情况愈加恶劣。他人所写的样式无人敢改，通常无法猜测它们是做什么用的，应用在哪些标记了，以及如果删掉会带来什么灾难。

其结果是：样式表必须只增不减。

你无法得知哪些代码可以安全地删除。因此常见的做法是用一些更具体的样式来覆盖现有样式，哪怕是在相对较小的项目上亦是如此。

单文件组件扭转乾坤

SFC 背后的思想十分简单：在一份 HTML 文件中编写组件，该文件可以包含描述组件样式的 <style> 和描述行为的 <script> 标记。

Svelte、Ractive、Vue 以及 Polymer 都是遵循这种模式。

（显然我们在文章其余内容都将使用 Svelte，但是如果使用模板会让你胆战心惊的话，其实你的担心是多余的，不过这又是另一个话题了，那你可以使用 Vue，它允许你在 SFC 中编写 JSX）

如果你从未接触过 Svelte，不妨先参看这篇文章：无招胜有招：为何我们没有及早悟到这个办法？，或者看看用户的评价。

应用这种模式，结果会发生几件美妙的事情：

• 组件的样式都是局部样式（scoped），不会向外泄露，没有不可预知的级联情况，彻底摆脱为了防止名称冲突而硬取的超级啰嗦的类名。

• 你无需再去文件夹中苦苦追查那些破坏你样式的规则。

• 编译器（例如 Svelte）能够识别和删除无效的样式，从此不再是“只增不减”了！

下面我们来试试探明究竟。

所有代码编辑器都能识别这些 CSS，其内置了自动完成、监测、语法高亮等等功能，无需额外的 JS 各种庞杂的工具。

同时，这些都是真正的 CSS，并非那些使用了驼峰命名及双引号无处不在的鱼目混珠的东西。

我们可以在 devTools 中对样式进行修葺调整，再复制粘贴回代码中，如此行云流水的工作方式，我再也无法离开这种酸爽。

不得不说，CSS source maps 功能已是开箱即用的，因此你能快速定位问题所在的行。

其重要性不言而喻：

当你使用所见即所得（WYSIWYG）的模式之时，你不会从组件树的角度去思考问题的，因此亟需一个万全之策使有问题的样式原形毕露。

如果组件本就出自他人之手，情况尤其堪忧。（我敢保证，这种 CSS 工作方式能极大提升你的生产力，离开 source maps，毋庸置疑你是在虚耗光阴，因为我曾经就是如此。）

Svelte 转译你的 CSS 选择器来实现让样式只应用在局部范围内，它同时也适用于受影响的元素的属性，尽管确切的机制无关紧要，并且可能会有所变化。

未使用的规则会被移除并发出警告，然后你可以将精简后的结果写到 .css 文件中。

还有一个实验性的新功能，就是可以编译组件为 Web Components，然后将样式封装到 shadow DOM 中（如果这刚好就是你所期望的话）。

一切皆有可能，因为你的 CSS 在标记的上下文中被解析（使用 css-tree）和静态分析。

静态分析为未来各种令人振奋的可能性打开大门：更智能的优化手段，各种提示……

但是如果你的样式需要在运行时才去动态计算的话，则做这些事情要困难得多。

我们也才刚刚开始。

但我们也可以借助工具来做啊 [X]！

如果你看了视频后的反应是：“很好，但是 —— 我们使用 TypeScript，且为各种编辑器编写插件，也能获得自动完成和语法高亮的功能啊。”

换而言之，为了获得与 CSS 等价的效果，而去折腾构建、文档、推进及维护等等一堆辅助性的项目，如果你认为这些事情意义重大……

那么，多说无益，你和我是道不同，不相为谋了！

我们仍然没有全部答案

综上所述。

诚然，CSS-in-JS 确实对一些悬而未决的问题给出了答案：

• 如何从 npm 安装样式？

• 我们如何重用一些定义在同一个地方的常量？

• 如何组合声明？

就个人而言，我认为所得的好处，没有超出上述这些问题的范围。

你的选择可能有不同的优先次序，使你放弃 CSS 有足够的理由。

但总的来说，你还是必须了解 CSS 的，不论热爱还是憎恶，最终都在所难免要学习它。

作为 Web 的守望者，我们可以做选择：

创建高深莫测的抽象，让 Web 开发者的学习曲线更加陡峭，或者一起解决 CSS 糟粕部分。

怎么选择，我已心中有数。

<The End>

- 窗明几净，静候时日变迁 -