作为一种将组件逻辑链接到其样式的方式，CSS-in-JS在某些场景中变得流行起来。Aggelos Arvanitakis 提醒开发人员，在某些情况下，不再能忽略CSS-in-JS的成本，并且提供了缓解策略。

Arvanitakis在一篇文章中指出，尽管CSS-in-JS带来了好处，但是，它仍可能在某些应用程序中造成性能问题。Arvanitakis把重点放在React和两个流行的CSS-in-JS库（styled-components和emotion）上，他比较了相同代码的两个版本，其中只有一个版本使用了CSS-in-JS样式。无样式版本如下所示：

import React from 'react';
const NormalDiv = props => <div {...props} />
const App = () => {
  const [randomValue, setRandomValue] = React.useState(0);
  return (
    <React.Fragment>
      {new Array(50).fill(null).map((__, i) => (
        <NormalDiv key={i}>Hello World</NormalDiv>
      ))}
      <button onClick={() => setRandomValue(Math.random())}>Force Rerender</button>
    </React.Fragment>
  );
};

样式版本如下所示：

import styled from '@emotion/styled';
const StyledDiv = styled.div``;
const App = () => {
  const [randomValue, setRandomValue] = React.useState(0);
  return (
    <React.Fragment>
      {new Array(50).fill(null).map((__, i) => (
        <StyledDiv key={i}>Hello World</StyledDiv>
      ))}
      <button onClick={() => setRandomValue(Math.random())}>Force Rerender</button>
    </React.Fragment>
  );
};

样式化的CSS-in-JS的实现比无样式版本要多花50%的时间在渲染上。尽管在很多情况下，很难察觉与CSS-in-JS相关的性能成本，但在其他情况下（如具有大型组件树），它的成本是很难忽略的。Arvantitakis猜测使用某些库观察到的性能成本可能要归因于它们修改组件树（使用Context并添加Context.Consumer以读取样式值）以及动态地应用样式（ style 标签包含动态注入的CSS ）。Arvanitakis解释道：

一切都非常正常，直到我实现了一个Table。我开始注意到渲染的速度很慢，尤其是行数超过50行之后。因此，我打开了devtools尝试研究它。

(……)
因此，总结来说，多个Context的使用者（这意味着React必须协调其他元素）以及动态样式附带的固有清理工作组合起来可能让应用程序的运行速度变慢了。

因此，Arvanitakis得出了如下建议：

1.不要过度组合样式化的组件
2.首选“静态”组件
3.避免不必要的React重渲染
4.研究零运行时CSS-in-JS库是否适合我们的项目
（……）如果我们的应用程序不需要支持主题化，并且也没有使用大量复杂的 csspro，那么，零运行时CSS-in-JS库可能是个不错的选择。我们可以得到的好处是，整个包的大小将缩减大约12KB，这是因为大多数CSS-in-JS库的大小在10KB到15KB之间，而零运行时库（如linaria）的大小不到1KB。

但是，Arvanitakis警告大家，性能重构只应该发生在遇到或测量到性能问题之后。JSS CSS-in-JS库的作者Oleg Isonen解释了4种常用的CSS-in-JS策略的权衡，并对比了CSS-in-JS库性能基准（截至2019年3月）。用选定的库进行基准测试得到的结果如下：

CSS-in-JS可能仅限于类似React这样的基于组件的框架。其他流行的框架，如Vue、Svelte或Angular使用其他的托管策略，为开发人员提供类似的好处（像作用域CSS和摇树优化CSS）。例如，Angular的开发人员可以用类似html的模板文件、CSS文件和JavaScript文件来定义其组件。然后，.js的文件将引用其他两个文件：

// ./app.component.js
import { Component } from '@angular/core';
@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.css']
})
export  class AppComponent {
  title = 'angular programming.';
}

后缀名为.js、.css和.html的文件应位于同一个目录中。另外，在模板和样式足够简短的情况下，Angular开发人员可能更喜欢直接在@Component定义中以字符串的形式将模板和样式放到一起。这两种方法在语法上是不同的，但都提供了相同的作用域优势。

Vue鼓励采用单个.vue文件，文件中包含style标记，其中含有CSS样式信息、类似html的模板和处理组件行为的JavaScript方法。类似的，Svelte读取.svelte文件中的组件定义，.svelte文件也包含同一文件中的样式、模板和逻辑信息。CSS-in-JS还是React等框架使用托管（colocation）的另一种形式，这些框架使用JavaScript渲染函数而不是模板。

正如Elm的创建者Evan Czaplicki在推文中这样写道，组件就是对象。托管和封装样式以及模板属性，并将它们与处理组件逻辑的方法处理放到一起是对单一职责原则（Single Responsibility Principle）的一种反应，就像Robert C. Martin所解释的：

换句话说，单一职责原则就是：
把基于相同原因而改变的事物放在一起。把出于不同原因而改变的事物分开来。

如果仔细想想，那么我们就会明白，这只是定义内聚和耦合的另一种方式。我们希望提高因相同原因而改变的事物之间的内聚性，并且，我们希望降低因不同原因而改变的事物之间的耦合性。

Arvanitakis的全文包括其他个人资料，读者可以上网查看。

原文链接：

CSS-in-JS Performance Cost - Mitigating Strategies

创作场景

CSS-in-JS 性能成本缓解策略