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

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

版本是：

风格化的CSS-in-JS实现的渲染时间似乎比非类型化版本长50%。虽然在很多情况下，与JS-in-JS相关的性能成本很难检测到，但在其他情况下(例如，以大型组件树为特征)，这种成本可能会变得很明显。Arvanitakis假设某些库的性能损失可能是由它们修改组件树的方式(使用上下文和添加上下文)造成的。读取样式值)并动态应用样式(样式包含动态注入的CSS标签)。阿尔瓦蒂奇解释道：

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

因此，alvan Tix提出以下建议：

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

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

三个。Js，css和。Html文件应该放在同一个目录中。此外，当模板和样式足够短或足够简单时，它们在[电子邮件保护]中是不同的，但它们提供了相同的范围优势。

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

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

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

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

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