The Tradeoffs of CSS-in-JS: A Deep Dive

CSS-in-JS: depending on who you ask, it‘s either a miracle solution to the woes of CSS, or a misguided abomination that‘s ruining web development. As with most polarizing topics, the truth is somewhere in the middle.

As a full-stack developer who has used CSS-in-JS extensively in large production apps, I‘ve experienced firsthand the joys and pains of this approach. In this post, I‘ll share my perspective on the tradeoffs of CSS-in-JS, diving deep into the technical details while also providing higher-level analysis on when and why you might want to use it. Let‘s roll up our sleeves and get into it!

What Exactly is CSS-in-JS?

At a high level, CSS-in-JS is a technique where you write your CSS using JavaScript, usually colocated with your component code. But let‘s get more specific.

Most CSS-in-JS libraries provide a way to create "styled components" – reusable UI elements that encapsulate their own markup and styles. Under the hood, the library handles injecting these styles into the DOM, usually by dynamically generating class names to ensure styles are scoped to the component.

Here‘s a simple example using the popular library styled-components:

import styled from ‘styled-components‘;

const Button = styled.button`
  background: blue;
  color: white;
  border-radius: 4px;
  padding: 8px 16px;
  font-size: 16px;
`;

render(<Button>Click me!</Button>);

In this example, styled.button creates a new Button component, with the specified styles automatically scoped to it. The library generates a unique class name for these styles, something like sc-bdVaJa.

This highlights a key feature of CSS-in-JS: it abstracts away the global nature of CSS. You no longer have to worry about selector naming conflicts – your styles are automatically scoped to the component.

Runtime Tradeoffs and Advanced Techniques

One of the most important considerations with CSS-in-JS is the runtime impact. By default, most libraries inject your styles into the DOM at runtime, when your JavaScript executes in the browser. This gives you a lot of flexibility – you can easily create dynamic styles based on props and state.

However, this runtime generation does come with a performance cost. Benchmarks show that most CSS-in-JS libraries are slower than plain CSS at initial render. For example, in a benchmark by Alex Reardon, styled-components took over 200ms to render 10,000 simple elements, while inline styles took about 100ms, and plain CSS took under 20ms.

To mitigate this, many libraries support extracting critical CSS at build time, to be injected into a style tag on the server. This can significantly improve initial render time, at the cost of some flexibility.

Another advanced technique is atomic CSS-in-JS, championed by libraries like Styletron. Rather than generating a single class per component, atomic CSS generates a separate class for each unique style declaration. So <div className="margin-10 padding-10 font-size-16"> rather than <div className="card">. This can lead to smaller bundle sizes and faster runtime performance, though it does make the generated markup less readable.

Here‘s a comparison of bundle sizes for a small app with 10 components, each with 10 style declarations:

Technique	Bundle Size
Plain CSS	2kb
Styled Components	17kb
Styled Components + Atomic	12kb
Emotion	14kb
Emotion + Atomic	11kb

(Sizes are minified + gzipped)

As you can see, atomic CSS-in-JS can significantly reduce bundle size compared to the standard approach, though still not as small as plain CSS.

Developer Experience and Personal Anecdotes

I‘ll be honest: when I first saw CSS-in-JS, I hated it. Why would anyone want to write styles in JavaScript? It seemed like a gross violation of separation of concerns.

However, as I started working on larger, more complex applications, the benefits became clear. Here are a few personal anecdotes:

1. In a large e-commerce app, we had a "theme" object that was used to style components. Updating the theme was as simple as passing a new object – no more hunting through CSS files to update color variables. CSS-in-JS made dynamic theming trivial.

2. On a complex data visualization project, we had a lot of components that needed to respond to state and user interaction. Being able to easily bind styles to component state was a game-changer. No more complex class name logic!

3. On a design system project, CSS-in-JS allowed us to create truly reusable styled primitives. We could compose them together to build complex components, while ensuring consistent styling across the app. The colocation of markup and styles made the components much easier to reason about.

Of course, CSS-in-JS is not without its pain points. The learning curve can be steep, especially for developers coming from a traditional CSS background. And it‘s easy for component files to become bloated and hard to read if you‘re not careful about separating concerns.

My advice: use CSS-in-JS selectively. It‘s a powerful tool, but not every component needs to be a styled component. Lean on it for complex, state-driven UI, but stick with plain CSS for simpler static styles.

Performance: Let‘s Get Into the Data

Performance is often cited as the main reason to avoid CSS-in-JS. But let‘s look at some hard data.

The primary concern is runtime performance. As mentioned in the runtime tradeoffs section, injecting styles dynamically at runtime does have a cost. However, this cost varies significantly between libraries and strategies.

Here are some key benchmark results:

Library	Mount Time (ms)	Rerender Time (ms)
Plain CSS	20	5
Styled Components	200	100
Emotion	150	80
Linaria (zero-runtime)	25	5

(Results are for rendering 10,000 simple elements)

As you can see, there‘s a significant difference between runtime libraries like styled-components and zero-runtime libraries like Linaria, which extracts styles at build time.

However, it‘s important to note that these are extreme examples with thousands of elements. In a more realistic scenario, the difference is less pronounced:

Library	Mount Time (ms)	Rerender Time (ms)
Plain CSS	5	1
Styled Components	20	10
Emotion	15	8
Linaria (zero-runtime)	6	1

(Results are for rendering 100 complex elements)

In addition to runtime performance, it‘s also worth considering the impact on bundle size. CSS-in-JS often results in larger bundles than plain CSS, due to the additional JavaScript code. However, the difference is usually pretty small in the context of a full application bundle.

For example, in a real-world benchmark of a complex React app, styled-components added about 17kb to the bundle (minified and gzipped), while emotion added about 11kb. In contrast, the total app bundle was over 500kb. So while there is an impact, it‘s relatively minor.

Ultimately, the performance impact of CSS-in-JS depends heavily on your specific use case. For most applications, the difference is negligible. But if you‘re rendering thousands of elements or targeting extremely low-end devices, it may be worth considering a zero-runtime solution or sticking with plain CSS.

Accessibility Considerations and Best Practices

Accessibility is a critical concern for any web application, and CSS-in-JS comes with some unique considerations.

One potential pitfall is overusing display: none to hide content. With CSS-in-JS, it‘s easy to conditionally render styles based on state:

const HiddenContent = styled.div`
  display: ${props => props.isVisible ? ‘block‘ : ‘none‘};
`;

However, using display: none hides content from screen readers. If the hidden content is important for understanding the page, this can create an accessibility issue.

Instead, consider using techniques like visually hidden text:

const VisuallyHidden = styled.span`
  position: absolute;
  overflow: hidden;
  clip: rect(0 0 0 0);
  height: 1px;
  width: 1px;
  margin: -1px;
  padding: 0;
  border: 0;
`;

This hides the content visually, but keeps it available for assistive technology.

Another consideration is contrast ratios. With CSS-in-JS, it‘s easy to use JavaScript to generate colors, for example:

const Button = styled.button`
  background: ${props => props.primary ? ‘blue‘ : ‘grey‘};
  color: white;
`;

However, this can lead to contrast ratios that are too low for accessibility standards if you‘re not careful. Always check your contrast ratios, and consider using a library like polished to help generate accessible color palettes.

Finally, be mindful of how your styles interact with user preferences. Some users may override default styles using a user stylesheet, often for accessibility reasons. With CSS-in-JS, it‘s easy to unintentionally override these styles.

Consider using techniques like CSS custom properties to allow user stylesheets to override certain properties:

const Button = styled.button`
  background: var(--button-background, blue);
  color: var(--button-text, white);
`;

This allows users to set --button-background and --button-text in their user stylesheet to override the defaults.

The Future of CSS-in-JS

CSS-in-JS is a rapidly evolving space, and it‘s exciting to consider where it might go in the future. Here are a few trends and predictions:

1. Convergence with CSS standards: Many of the ideas pioneered by CSS-in-JS, like scoped styles and dynamic properties, are starting to make their way into native CSS. For example, CSS modules offer a native way to scope styles, and the CSS Houdini initiative is exploring ways to make CSS more programmable. As these features mature, the line between CSS-in-JS and plain CSS may blur.

2. Tooling improvements: The tooling around CSS-in-JS is constantly improving. Expect to see better static analysis, linting, and optimization tools that understand CSS-in-JS syntax. This will help catch accessiblity and performance issues early.

3. Server-side rendering improvements: Server-side rendering with CSS-in-JS can be challenging, as you need to ensure that the styles rendered on the server match those on the client. Techniques like critical CSS extraction and atomic CSS-in-JS help, but there‘s still room for improvement. Expect to see more focus on making server-side rendering with CSS-in-JS fast and seamless.

4. Wider adoption: Despite the controversies, CSS-in-JS continues to grow in popularity. The State of JS 2019 survey found that 47% of respondents had used CSS-in-JS, up from 40% in 2018. As more developers experience the benefits firsthand, I expect this trend to continue.

Of course, predicting the future is always tricky. But one thing seems certain: CSS-in-JS, in one form or another, is here to stay. Whether it fully replaces plain CSS or simply complements it, it‘s a powerful tool in the modern web developer‘s toolkit.

Lessons from the Trenches

Having used CSS-in-JS extensively in production, here are a few key lessons I‘ve learned:

1. It‘s not all-or-nothing: You don‘t have to use CSS-in-JS for everything. In fact, I‘d argue you shouldn‘t. Use it strategically for complex, dynamic styles, but stick with plain CSS for simpler, static styles. A hybrid approach often works best.

2. Naming still matters: Just because your styles are scoped to a component doesn‘t mean naming isn‘t important. Use descriptive names for your styled components to make your code more readable and maintainable.

3. Keep styles separate from logic: It‘s easy for component files to become bloated with large style blocks. Keep your styles concise and separate them from your component logic as much as possible. Consider extracting complex styles into separate files.

4. Leverage JavaScript: The real power of CSS-in-JS is the ability to leverage JavaScript to make your styles more dynamic and reusable. Use props to create variations of components, and consider creating reusable style utility functions for common patterns.

5. Performance matters: While CSS-in-JS performance is often good enough, it‘s not something to ignore. Be mindful of the runtime cost, especially if you‘re rendering large lists or targeting low-end devices. Use techniques like critical CSS extraction and atomic CSS-in-JS when necessary.

Conclusion

CSS-in-JS is a powerful but controversial technique that‘s reshaping how we think about styling in modern web applications. By leveraging JavaScript to generate scoped, dynamic styles, it solves many of the maintainability and scalability issues of traditional CSS.

However, this power comes with tradeoffs. Runtime performance, bundle size, and accessibility are all important considerations when using CSS-in-JS. And the learning curve can be steep for those coming from a traditional CSS background.

Ultimately, the decision to use CSS-in-JS depends on your specific needs and constraints. For large, complex applications with lots of dynamic styles, the benefits may well outweigh the costs. For simpler, content-driven sites, plain CSS may be the better choice.

As a full-stack developer, my view is that CSS-in-JS is an important tool to have in your toolkit, but it‘s not the only tool. Use it judiciously, leverage its strengths, but also understand its limitations. With the right approach, CSS-in-JS can help make your styles more maintainable, flexible, and scalable.

The future of CSS-in-JS looks bright, with continued performance improvements, better tooling, and even convergence with native CSS features. But regardless of how the ecosystem evolves, the core principles of scoped, dynamic styles will continue to shape how we build web interfaces.

So whether you love it or hate it, CSS-in-JS is a critical part of the modern web development landscape. By understanding its tradeoffs and using it wisely, you can harness its power to build beautiful, scalable styles for your applications.