共计 2244 个字符，预计需要花费 6 分钟才能阅读完成。
这是将来的趋势所向，如是我行。
留神：原文发表于 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）可能辨认和删除有效的款式，从此不再是“只增不减”了！
上面咱们来试试探明到底。
< 因不反对插入视频，点击此处观看视频 >
这就是所谓的“use the platform”？
所有代码编辑器都能辨认这些 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\>
– 窗明几净，静候时日变迁 –
