Sam Magura是 Spot 的软件工程师，也是活跃的Emotion库维护者。最近，他详细解释了 Spot 公司为什么放弃运行时 CSS-in-JS 库 Emotion，而选择了Sass模块——运行时开销、负载开销和服务器端渲染问题导致了较差的用户体验。
在他的博文中，Magura 首先回顾了运行时 CSS-in-JS 的好处。
今天的 Web 应用程序通常实现为一组协作的组件。在使用运行时 CSS-in-JS 库时，开发人员定义组件的样式以及组件标记和逻辑。如果以不正确的方式修改或删除了组件样式，就很难修改或删除组件代码。这解决了大型应用程序中充斥着未被检测到的过时样式规则的问题。但这样的应用程序下载和执行都比较笨重，对用户体验有负面影响。
将 CSS 规则的作用域严格限定到相关的组件就很难会无意影响到其他组件的样式。如果没有组件作用域，CSS 的级联和专一性规则可能会导致不相关组件的样式定义发生渗透。
最后，使用完备的图灵语言，如 JavaScript，开发人员可以完全自由地表达组件样式和组件逻辑之间的关系。如果组件样式不是静态的，并且需要根据用户操作或应用程序环境中的变更进行动态更新时，这样就很方便了。
不过，Magura 根据他对 Spot 代码库的研究得出结论，CSS-in-JS 的坏处大于好处：
所以，这就是我们放弃 CSS-in-JS 的原因——运行时性能成本太高了。
CSS-in-JS 可能会因其运行时和负载开销而对用户体验产生负面的影响。
一方面，在渲染时动态计算和更新样式可能会导致渲染变慢。Magura 比较了 Spot 用运行时 CSS-in-JS 库 Emotion 实现的代码库组件的渲染时间与用 Sass 模块实现的代码库组件的渲染时间（在构建时编译为普通的 CSS 文件）。对比显示，使用 Emotion 库的渲染时间几乎翻倍（27.7 毫秒对 54 毫秒）。开发人员可以从这篇博文中查看实验数据、火焰图分析等等。
另一方面，将 CSS-in-JS 库添加到应用程序代码中会加大浏览器下载的代码包，可能会降低应用程序的启动速度。Emotion 大约 8 KB（最小化后），而style-components，一个流行的 CSS-in-JS 库，是 12 KB。
有趣的是，运行时 CSS-in-JS 库执行的动态插入 CSS 样式规则可能并不总是与生态系统的其他部分很好地配合。
关于 React 18，Sebastian Markage在 GitHub Issues 中向使用 React 并发渲染功能的开发人员提出了如下的警告：
这是一个 CSS 库（动态生成新规则并将它们与