{"@attributes":{"version":"2.0"},"channel":{"title":"DEV Community: Sam Magura","description":"The latest articles on DEV Community by Sam Magura (@srmagura).","link":"https:\/\/dev.to\/srmagura","image":{"url":"https:\/\/media2.dev.to\/dynamic\/image\/width=90,height=90,fit=cover,gravity=auto,format=auto\/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F710804%2F8be2ddc2-d75f-47fc-a72c-ff8242808815.jpg","title":"DEV Community: Sam Magura","link":"https:\/\/dev.to\/srmagura"},"language":"en","item":[{"title":"Why We're Breaking Up with CSS-in-JS","pubDate":"Sun, 16 Oct 2022 19:52:59 +0000","link":"https:\/\/dev.to\/srmagura\/why-were-breaking-up-wiht-css-in-js-4g9b","guid":"https:\/\/dev.to\/srmagura\/why-were-breaking-up-wiht-css-in-js-4g9b","description":"

Hi, I'm Sam \u2014 software engineer at Spot<\/a> and the 2nd most active maintainer of Emotion<\/a>, a widely-popular CSS-in-JS library for React. This post will delve into what originally attracted me to CSS-in-JS, and why I (along with the rest of the Spot team) have decided to shift away from it.<\/p>\n\n

We'll start with an overview of CSS-in-JS and give an overview of its pros & cons. Then, we'll do a deep dive into the performance issues that CSS-in-JS caused at Spot and how you can avoid them.<\/p>\n\n

\n \n \n What is CSS-in-JS?\n<\/h2>\n\n

As the name suggests, CSS-in-JS allows you to style your React components by writing CSS directly in your JavaScript or TypeScript code:<\/p>\n\n

\n
\n\n\/\/ @emotion\/react (css prop), with object styles<\/span>\nfunction<\/span> ErrorMessage<\/span>({<\/span> children<\/span> })<\/span> {<\/span>\n  return <\/span>(<\/span>\n    <<\/span>div<\/span>\n      css<\/span>=<\/span>{<\/span>{<\/span>\n        color<\/span>:<\/span> '<\/span>red<\/span>'<\/span>,<\/span>\n        fontWeight<\/span>:<\/span> '<\/span>bold<\/span>'<\/span>,<\/span>\n      }<\/span>}<\/span>\n    ><\/span>\n      {<\/span>children<\/span>}<\/span>\n    <\/<\/span>div<\/span>><\/span>\n  );<\/span>\n}<\/span>\n\n\/\/ styled-components or @emotion\/styled, with string styles<\/span>\nconst<\/span> ErrorMessage<\/span> =<\/span> styled<\/span>.<\/span>div<\/span>`\n  color: red;\n  font-weight: bold;\n`<\/span>;<\/span>\n\n\n<\/code><\/pre>\n\n<\/div>\n\n
This article focuses on runtime CSS-in-JS<\/strong>, a category which includes both styled-components and Emotion. Runtime CSS-in-JS simply means that the library interprets and applies your styles when the application runs. We'll briefly discuss compile-time CSS-in-JS at the end of the article.<\/p>\n\n
\n  \n  \n  The Good, The Bad, and the Ugly of CSS-in-JS\n<\/h2>\n\n
Before we get into the nitty-gritty of specific CSS-in-JS coding patterns and their implications for performance, let's start with a high-level overview of why you might choose to adopt the technology, and why you might not.<\/p>\n\n
\n  \n  \n  The Good\n<\/h3>\n\n
1. Locally-scoped styles.<\/strong> When writing plain CSS, it's very easy to accidentally apply styles more widely than you intended. For example, imagine you're making a list view where each row should have some padding and a border. You'd likely write CSS like this:<\/p>\n\n
\n
\n\n   .row<\/span> {<\/span>\n     padding<\/span>:<\/span> 0.5rem<\/span>;<\/span>\n     border<\/span>:<\/span> 1px<\/span> solid<\/span> #ddd<\/span>;<\/span>\n   }<\/span>\n\n\n<\/code><\/pre>\n\n<\/div>\n\n
Several months later when you've completely forgotten about the list view, you create another component that has rows. Naturally, you set className=\"row\"<\/code> on these elements. Now the new component's rows have an unsightly border and you have no idea why! While this type of problem can be solved by using longer class names or more specific selectors, it's still on you as the developer to ensure there are no class name conflicts.<\/p>\n\n
CSS-in-JS completely solves this problem by making styles locally-scoped by default. If you were to write your list view row as<\/p>\n\n
\n
\n\n<<\/span>div<\/span> css<\/span>=<\/span>{<\/span>{<\/span> padding<\/span>:<\/span> '<\/span>0.5rem<\/span>'<\/span>,<\/span> border<\/span>:<\/span> '<\/span>1px solid #ddd<\/span>'<\/span> }<\/span>}<\/span>><\/span>...<\/<\/span>div<\/span>><\/span>\n\n\n<\/code><\/pre>\n\n<\/div>\n\n
there is no way the padding and border can accidentally get applied to unrelated elements.<\/p>\n\n
\n
Note: CSS Modules also provide locally-scoped styles.<\/p>\n<\/blockquote>\n\n
2. Colocation.<\/strong> If using plain CSS, you might put all of your .css<\/code> files in a src\/styles<\/code> directory, while all of your React components live in src\/components<\/code>. As the size of the application grows, it quickly becomes difficult to tell which styles are used by each component. Often times, you will end up with dead code in your CSS because there's no easy way to tell that the styles aren't being used.<\/p>\n\n
A better approach for organizing your code is to include everything related to a single component in same place.<\/strong> This practice, called colocation, has been covered in an excellent blog post<\/a> by Kent C. Dodds.<\/p>\n\n
The problem is that it's hard to implement colocation when using plain CSS, since CSS and JavaScript have to go in separate files, and your styles will apply globally regardless of where the .css<\/code> file is located. On the other hand, if you're using CSS-in-JS, you can write your styles directly inside the React component that uses them! If done correctly, this greatly improves the maintainability of your application.<\/p>\n\n
\n
Note: CSS Modules also allow you to colocate styles with components, though not in the same file.<\/p>\n<\/blockquote>\n\n
3. You can use JavaScript variables in styles.<\/strong> CSS-in-JS enables you to reference JavaScript variables in your style rules, e.g.:<\/p>\n\n
\n
\n\n\/\/ colors.ts<\/span>\nexport<\/span> const<\/span> colors<\/span> =<\/span> {<\/span>\n  primary<\/span>:<\/span> '<\/span>#0d6efd<\/span>'<\/span>,<\/span>\n  border<\/span>:<\/span> '<\/span>#ddd<\/span>'<\/span>,<\/span>\n  \/* ... *\/<\/span>\n};<\/span>\n\n\/\/ MyComponent.tsx<\/span>\nfunction<\/span> MyComponent<\/span>({<\/span> fontSize<\/span> })<\/span> {<\/span>\n  return <\/span>(<\/span>\n    <<\/span>p<\/span>\n      css<\/span>=<\/span>{<\/span>{<\/span>\n        color<\/span>:<\/span> colors<\/span>.<\/span>primary<\/span>,<\/span>\n        fontSize<\/span>,<\/span>\n        border<\/span>:<\/span> `1px solid <\/span>${<\/span>colors<\/span>.<\/span>border<\/span>}<\/span>`<\/span>,<\/span>\n      }<\/span>}<\/span>\n    ><\/span>\n      ...\n    <\/<\/span>p<\/span>><\/span>\n  );<\/span>\n}<\/span>\n\n\n<\/code><\/pre>\n\n<\/div>\n\n
As this example shows, you can use both JavaScript constants (e.g. colors<\/code>) and React props \/ state (e.g. fontSize<\/code>) in CSS-in-JS styles. The ability to use JavaScript constants in styles reduces duplication in some cases, since the same constant does not have to be defined as both a CSS variable and a JavaScript constant. The ability to use props & state allows you to create components with highly-customizable styles, without using inline styles. (Inline styles are not ideal for performance when the same styles are applied to many elements.)<\/p>\n\n
\n  \n  \n  The Neutral\n<\/h3>\n\n
1. It's the hot new technology.<\/strong> Many web developers, myself included, are quick to adopt the hottest new trends in the JavaScript community. Part of this is rationale, since in many cases, new libraries and frameworks have proven to be massive improvements over their predecessors (just think about how much React enhances productivity over earlier libraries like jQuery). On the other hand, the other part of our obsession with shiny new tools is just that \u2014 an obsession. We're afraid of missing out on the next big thing, and we might overlook real drawbacks when deciding to adopt a new library or framework. I think this has certainly been a factor in the widespread adoption of CSS-in-JS \u2014 at least it was for me.<\/p>\n\n
\n  \n  \n  The Bad\n<\/h3>\n\n
1. CSS-in-JS adds runtime overhead.<\/strong> When your components render, the CSS-in-JS library must \"serialize\" your styles into plain CSS that can be inserted into the document. It's clear that this takes up extra CPU cycles, but is it enough to have a noticeable impact on the performance of your application? We'll investigate this question in depth in the next section.<\/strong><\/p>\n\n
2. CSS-in-JS increases your bundle size.<\/strong> This is an obvious one \u2014 each user who visits your site now has to download the JavaScript for the CSS-in-JS library. Emotion is 7.9 kB<\/a> minzipped and styled-components is 12.7 kB<\/a>. So neither library is huge, but it all adds up. (react<\/code> + react-dom<\/code> is 44.5 kB for comparison.)<\/p>\n\n
3. CSS-in-JS clutters the React DevTools.<\/strong> For each element that uses the css<\/code> prop, Emotion will render <EmotionCssPropInternal><\/code> and <Insertion><\/code> components. If you are using the css<\/code> prop on many elements, Emotion's internal components can really clutter up the React DevTools, as seen here:<\/p>\n\n
\"The<\/a><\/p>\n\n
\n  \n  \n  The Ugly\n<\/h3>\n\n
1. Frequently inserting CSS rules forces the browser to do a lot of extra work.<\/strong> Sebastian Markb\u00e5ge<\/a>, member of the React core team and the original designer of React Hooks, wrote an extremely informative discussion<\/a> in the React 18 working group about how CSS-in-JS libraries would need to change to work with React 18, and about the future of runtime CSS-in-JS in general. In particular, he says:<\/p>\n\n
\n
In concurrent rendering, React can yield to the browser between renders. If you insert a new rule in a component, then React yields, the browser then have to see if those rules would apply to the existing tree. So it recalculates the style rules. Then React renders the next component, and then that component discovers a new rule and it happens again.<\/p>\n\n
This effectively causes a recalculation of all CSS rules against all DOM nodes every frame while React is rendering.<\/strong> This is VERY slow.<\/p>\n<\/blockquote>\n\n
Update 2022-10-25:<\/strong> This quote from Sebastian is specifically referring to performance in React Concurrent Mode, without<\/strong> useInsertionEffect<\/code>. I recommend reading the full discussion if you want an in-depth understanding of this. Thanks to Dan Abramov for pointing out<\/a> this inaccuracy on Twitter.<\/p>\n\n
The worst thing about this problem is that it's not a fixable issue (within the context of runtime CSS-in-JS). Runtime CSS-in-JS libraries work by inserting new style rules when components render, and this is bad for performance on a fundamental level.<\/p>\n\n
2. With CSS-in-JS, there's a lot more that can go wrong, especially when using SSR and\/or component libraries.<\/strong> In the Emotion GitHub repository, we receive tons<\/em> of issues that go like this:<\/p>\n\n
\n
I'm using Emotion with server-side rendering and MUI\/Mantine\/(another Emotion-powered component library) and it's not working because...<\/p>\n<\/blockquote>\n\n
While the root cause varies from issue to issue, there are some common themes:<\/p>\n\n
styled-components<\/a> and Emotion<\/a> are the most popular CSS-in-JS libraries in the React community. While I have only used Emotion, I believe virtually all points in this article apply to styled-components as well.<\/p>\n\n