在某些情况下，CSS-in-JS已经成为一种流行的方式来将组件逻辑地链接到它们的样式。Aggelos Arvanitakis提醒开发人员，在某些情况下，CSS-in-JS的成本已经不能再被忽视，并提供了缓解策略。

Arvanitakis在一篇文章中指出，尽管JS-in-JS带来了很多好处，但在一些应用程序中仍然会造成性能问题。Arvanitakis重点介绍了React和两个流行的CSS-in-JS库(样式-组件和情感)，并比较了相同代码的两个版本，其中只有一个版本使用了CSS-in-JS样式。无样式版本如下：

版本为：

风格化的CSS-in-JS实现的渲染时间似乎比非类型化版本长50%。尽管与JS-in-JS相关联的性能成本在许多情况下很难感知，但在其他情况下(例如，以大组件树为特征)可能会变得很明显。Arvanitakis假设一些库的性能损失可能是由它们如何修改组件树(使用上下文和添加上下文)引起的。读取样式值)和动态应用样式(样式包含动态注入的CSS标记)。阿尔瓦蒂克斯解释说：

在我意识到有一张桌子之前，一切都很好。我开始注意到渲染速度比较慢，尤其是行数超过50的时候。因此，我打开了我的开发工具，尝试和研究它。(……)所以，总之，动态风格(这意味着协调其他元素的反应)和内务处理中固有的多上下文消费者可能会减慢应用程序的速度。

因此，阿尔瓦蒂克斯提出了以下建议：

但是，Arvanitakis警告说，性能重构应该仅在遇到或测量性能问题后执行。JS-in-JS库的作者Oleg Isonen解释了四种常用的CSS-in-JS策略之间的权衡，并链接到比较CSS-in-JS库性能的基准(截至2019年3月)。使用选定的库运行基准测试结果，如下所示：

JS中的CSS可能局限于类似于响应的基于组件的框架。其他流行的框架，如Vue、Svelte或Angular，也使用其他托管策略为开发人员提供类似的好处(如范围有限的CSS和可以撼动树的CSS)。例如，Angular开发人员可以使用类似html的模板文件、css文件和JavaScript文件来定义他们的组件。然后。js文件将引用另外两个：

三个。Js、css和。Html文件应该放在同一目录下。此外，当模板和样式足够短或足够简单时，Angular开发人员可能更喜欢在@Component的定义中直接使用字符串形式的模板和样式。这两种方法在语法上不同，但它们提供了相同的范围优势。

Vue推广单打。Vue文件，其中包含样式标签，包括CSS样式信息、类似html的模板和用于处理组件行为的JavaScript方法。同样，Svelte也是这样写的。Svelte文件，其中也包含相同的文件、样式、模板和逻辑信息。是React等框架使用的另一种定位方法，它使用JavaScript来呈现函数，而不是模板。

正如Elm创始人Evan Czaplicki在推特上所说，组件就是对象。处理组件逻辑的方法似乎响应了罗伯特C马丁在：

单一责任原则的另一种说法是：

收集因为同样的原因而改变的东西。将因不同原因而改变的事物分开。

仔细想想，你会发现这只是定义内聚耦合的另一种方式。我们希望增加因相同原因而改变的事物之间的凝聚力，我们希望减少因不同原因而改变的事物之间的耦合。