只写CSS的禅

我想说这是未来，但我们已经着手实践了。

CSS不受欢迎是一个很普遍的现象。导致这一现象的原因有很多，但可以归结为：CSS的不可预测性。如果你在开发中从未有过这种经历:过调试一个样式时，一不小心破坏布局，让一个看起来毫不相关的地方样式错乱。那只能说明两个问题，要么你是一个萌新菜鸟，要么你比我们大多数程序员优秀得多。

所以，JS社区的成员们撸起袖子开始行动了。 在过去的几年中，如寒武纪大爆炸一般出现了很多旨在规范CSS表现的库，其中大部分都涉及到CSS-in-JS。

你可能没有意识到：那些CSS中最严重的问题，不通过CSS-in-JS的方式也同样能够解决。如果解决了这些问题，那么编写CSS不仅不会是一种困扰，反而会成为一种享受。然而，你不需要为了寻找解决方案而采用可能会引入更多问题的CSS-in-JS。

本文的目的并非想批评或否定CSS-in-JS社区所做出的努力。该社区是JS生态中相当活跃的领域之一，每周都会涌现出新的想法。相反地，我的意图是为了阐明，基于原生CSS组件化是另一种令人愉悦的替代解决方案。

CSS 最大的问题

CSS中的一切都是全局的。正因如此，经常会出现一个为局部设计的样式却影响到另外一个地方的情况。为了处理这种情况，开发者们通常会求助于粗犷的命名规范（并不是‘规则’，因为它们很难执行），但多数情况下只是徒增权重计算的风险。

当你在团队中开发时，情况会变得更糟。没人敢随意涉足他人风格的代码，因为通常不清楚他们做了什么，用的什么标记，如果删除它们会招致什么样的灾难。

这一切的结果就导致了累加样式表的产生。无法得知哪些代码可以安全地删除，所以通常的解决方法就是在之后添加更具体的新样式覆盖已有样式，即便在小型项目中也是如此。

单文件组件解决所有问题

单文件组件背后的思想很简单：将组建写在一个HTML（可选的）文件中，并且加一个 and属性描述组件的样式和行为。Svelte, Ractive, Vue 和 Polymer都能够支持这一简单的写法。

如果你是第一次接触Svelte，可以阅读介绍博客(https://svelte.technology/blog/frameworks-without-the-framework)，或者阅读这些推荐(https://twitter.com/sveltejs/status/901818106309476352)。

(很显然，本文的剩余部分我们将会使用Svelte。但如果使用模板语言让你听起来不寒而栗，那你就错了，不过这个话题我们改天讨论，你可以就用Vue并在你的单文件组件中使用JSX语法。)

有几件美妙的事情发生了:

• 你的样式会以组件为作用域。不再泄漏，不再有无法预测的级联。也不再有为了避免冲突而设计的类名。
• 你不需要通过搜索文件夹结构来找出那个破坏你代码的规则。
• 编译器(在Svelte的例子中)可以识别并移除未使用的样式。再也不会有累加样式表了!

我们来看看实际情况是怎样的。

这就是他们所谓的“利用平台”吗?

所有的代码编辑器早就能够识别CSS，所以，你可以轻松实现代码补全，语法检查，以及语法高亮等，这些都不需要安装会带来JS疲劳的额外工具。

而且，正因为是真正的CSS，而不是繁杂的驼峰式模拟引用，我们可以利用devtools进行代码调试，之后再将调好的代码粘贴到工作区，我个人十分依赖这种开发方式。请注意，我们从调试框中可以得到CSS的资源路径映射表，所以，我们可以快速而准确地找到有问题的代码行。很难夸大这一点的重要性：当你在使用所见即所得的开发模式时，你并没有考虑到你的组件树，所以，有一个可靠的途径来弄清这些鬼样式都哪来的是绝对必要的。如果这个组件最初是别人写的，那就更有必要了。（我向您保证，这是对您的CSS工作流生产力的大力提升。如果在没有资源映射表的情况下写CSS，你将会浪费大量时间，我之前就是如此。）

Svelte通过转换你的选择器(运用一些同样作用于元素的属性，具体实现原理并不重要) 来实现局部作用域.它会提示并删除那些没有被使用的样式规则，并将文件压缩合并产出一个 .css的文件。还有一个更具实验性的选择，你可以利用影子DOM将样式进行封装，产出一个web组件，如果你喜欢的话。

这些都是有可能的，因为你的CSS已经被解析成css树 ，并在你标记的上下文中进行静态分析。 静态分析开启了未来许多令人兴奋的可能性，例如智能优化。开放辅助功能（A11y）工作组表示，如果你的样式依赖运行时的计算，它会更难维护。我们才刚刚起步。

但是我们可以通过工具去做X!

如果你对video的反应是“很好，但如果我们使用TypeScript并为每个编辑器写些插件，那么我们就能够实现语法补全及高亮显示了”。换句话讲，如果你为了达到与CSS一致的表现而愿意去构建和维护一套附属系统的话，那么，也许我们终究无法达成共识！

我们还没有得到所有的答案

不得不说，CSS-in-JS确实为一些延续已久的问题指出了解决方案:

• 我们如何从npm上安装样式?
• 定义在一个地方的常量如何复用?
• 我们如何撰写声明?

就我个人而言，并未发现有上述优点之外的议题。也许你对优先级有自己的取舍，它们可能让你有足够的理由放弃CSS。但最终，你还是要了解CSS的。无论你是爱它还是恨它，你至少要学会它。作为web的维护者，我们必须做出选择：是选择深层抽象让学习web技术的曲线更加陡峭，还是一起努力来修复CSS的缺陷。我清楚自己的选择。

小手一抖，资料全有。长按二维码关注京程一灯，阅读更多技术文章和业界动态。