Future of runtime CSS-in-JS

[robinmetral]

Hi people!

I'd like to open up a discussion about the last section of the React 18 Library Upgrade Guide for CSS-in-JS libs.

Show the section, copy-pasted in here for convenience

Future

While this technique for generating CSS is popular today, we've found that it has a number of problems that we'd like to avoid. Therefore we don't have plans for adding any solutions upstream to handle this in React. For the time being, we expect this to have to be handled by third-party libraries such as in this guide.

Our preferred solution is to use <link rel="stylesheet"> for statically extracted styles and plain inline styles for dynamic values. E.g. <div style={{...}}>. You could however build a CSS-in-JS library that extracts static rules into external files using a compiler. That's what we use at Facebook.

It's tempting to use dynamically generated style sheets since it contains only the rules that are active on the page right now. However, this comes at a cost. Usually at the expense of runtime cost. It also comes at a cost of inserting new rules frequently which invalidates a lot of the work that has already been done.

Shared stylesheets are efficient to parse and are very cacheable. By extracting them into shared styles you are also effectively batching a lot of that work up front. This lets you avoid doing that work later on as the user starts interacting with the page.

If you also use techniques like atomic CSS or other per-rule class names (e.g. tailwind), the CSS file sizes tends to plateau and not grow much in size since a lot of parts of a page tend to use similar rules for different components.

Truly dynamic rules can't be done this way but those can use inline styles (<div style={{...}}>). Inline styles doesn't suffer from invalidating the whole page's rules and only applies to the node they're applied to. Unfortunately, the performance of reparsing similar rules means that using only inline styles isn't optimal neither. However, when combined, these two techniques work well.

A possibly strategy that might help minimize these quirks in the future would be to use Shadow DOM to scope the rule invalidation, however, that currently comes with a lot of other downsides so is not a feasible strategy atm IMO.

---

First things first: I've caught up on the discussions about React 18 compatibility and it's great that Emotion.js has already adopted the new useInsertionEffect hook. Thank you! 🙌

My remaining concerns are specifically about future versions of React:

While this technique for generating CSS is popular today, we've found that it has a number of problems that we'd like to avoid. Therefore we don't have plans for adding any solutions upstream to handle this in React.

So let's say that in React 20, something makes runtime CSS-in-JS impossible (or affects performance too much for this technique to make sense anymore). If I understand right, React wouldn't be providing a workaround.

So my questions:

• Is there a plan? Is Emotion.js considering reintroducing some kind of static extraction as recommended in the guide above?
  • If not: should people considering Emotion.js for styling React be warned about this?
  • If not: should existing users start thinking about migrating? Migration may take a long time for large codebases relying on Emotion.js, even though alternatives like Linaria have a similar API.
• Can we (Emotion.js users) help somehow?

Apologies if this has already been discussed elsewhere, and thanks in advance for your thoughts!

[srmagura]

Thank you for this thoughtful post 😃. I had not seen the discussion you linked, though our primary maintainer @Andarist clearly has.

Is there a plan?

We haven't discussed this topic, though @Andarist may already be thinking about it. I will make sure to discuss this with him if he doesn't comment here directly.

Is Emotion.js considering reintroducing some kind of static extraction as recommended in the guide above?

I think this would be such a major change to Emotion that it is not worth doing. My intuition says that it would be easier to write a new library than making Emotion work with static extraction.

should people considering Emotion.js for styling React be warned about this?

Maybe — I will think about it.

should existing users start thinking about migrating? Migration may take a long time for large codebases relying on Emotion.js, even though alternatives like Linaria have a similar API.

Another maybe. If performance is super critical to your use case, I would not recommend runtime CSS-in-JS — it's convenient but that comes at a cost.

I looked at Linaria and it does not seem to be very popular or active. I have heard of Vanilla Extract which is not terribly popular right now but seems to be gaining traction. For completeness, I will also mention CSS Modules / Sass Modules. It will also be interesting if Meta open sources stylex, their internal library which is mentioned in the react18-wg discussion.

Can we (Emotion.js users) help somehow?

Right at this moment, probably not — but if this turns out to be an actionable issue there may be opportunities to help. If you want to contribute to Emotion in general, feel free to DM me (@Sam Magura) in our Slack. Link is in the navbar on our website.

Edit: cc @mitchellhamilton

[robinmetral]

Thank you for your thoughts @srmagura! 🙌

If Emotion is planning on remaining runtime-only, I'd recommend documenting the tradeoffs. Like you said, there are many benefits to Emotion (DX, convenience, ecosystem), but developers may not want to default to it: performance cost today is one reason, future compatibility with React is another. If I can help with this, let me know!

About alternatives, I mostly mentioned Linaria because we were looking into it at @sumup. Its adoption by Airbnb seems like a sign that the library will continue being maintained and improved. I personally love CSS Modules (with or without preprocessors) but migration cost from CSS-in-JS would unfortunately be too high for us—as I expect it would be for other large projects. And I hadn't heard of stylex by name! I'll be keeping an eye on this too 👀

But of course, we'd love to stay with Emotion! We're just trying to understand what the future for it looks like, since any migration for us would have a high cost and take a lot of time.

I'll be looking forward to hearing from @Andarist on this topic as well! Thanks again for engaging and have a great Tuesday ☀️

[Andarist]

So let's say that in React 20, something makes runtime CSS-in-JS impossible (or affects performance too much for this technique to make sense anymore). If I understand right, React wouldn't be providing a workaround.

I think that this is very unlikely. CSS-in-JS might not be "recommended" by the React team but I doubt that it will become impossible.

Is there a plan? Is Emotion.js considering reintroducing some kind of static extraction as recommended in the guide above?

I don't think we plan to introduce such things. There are two primary reasons for this:

1. we don't have time to develop this
2. it would likely make Emotion to be a different library

Even though CSS-in-JS has its drawbacks it might be worth the tradeoff for many people. The lack of the required build step is a huge win for many projects.

If not: should people considering Emotion.js for styling React be warned about this?

We could make this clear in the docs - but to be honest I know plenty of fast sites using Emotion. It's not always about the tool itself but also how it's utilized by the apps/sites.

If not: should existing users start thinking about migrating? Migration may take a long time for large codebases relying on Emotion.js, even though alternatives like Linaria have a similar API.

This should be judged on the case by case basis. It's not that Emotion became any slower since it got popular, in fact - it got faster in v11 since we've switched to the new version of the underlying parser (Stylis) and it has been improved in v4 (which I've also helped to get across the finish line). The question is - why it was OK to start using Emotion but it's not OK to continue using it any longer? 😉 I know the answer - it's hype. Perhaps we should be talking about actual perf numbers, tradeoffs, maintainability and other stuff - and not about the hype.

Can we (Emotion.js users) help somehow?

You always are welcome to help out :)

---

That being said... there might be hope for people using Emotion who wants to stop relying on the runtime as much. There is this beautiful Compiled project that you can find here: https://compiledcssinjs.com/

I have not been checking it out lately so I'm not exactly sure what is its current status but I see that it's still active. If you care about this I would recommend you to reach out to their team and help out there. This is also part of the reason why I don't plan to do anything about the static extraction here - cause there are already projects doing this that aim to be a drop-in replacement for Emotion 😉

[robinmetral]

Thanks a lot for your reply @Andarist! It's very appreciated, and makes a lot of sense.

I think that this is very unlikely. CSS-in-JS might not be "recommended" by the React team but I doubt that it will become impossible.

I'm glad that you're optimistic here. This is our main concern with continuing to use Emotion—we've lived happily with the performance implications for years, so were mostly worried about a potential blocker because of a future React version

I know plenty of fast sites using Emotion. It's not always about the tool itself but also how it's utilized by the apps/sites.

This is a good point. On a related note, I recently saw new additions to the docs¹ with interesting considerations when it comes to best practices for using Emotion.js. There are so many ways to use the library that implementations don't seem to automatically fall into a pit of success.

A thing that we could consider, for people wanting to continue using Emotion.js but with best practices in mind (for perf but also maintainability, DX etc.), would be to build tooling like ESlint rules to help developers use Emotion.js in the best possible way.

The question is - why it was OK to start using Emotion but it's not OK to continue using it any longer? 😉 I know the answer - it's hype. Perhaps we should be talking about actual perf numbers, tradeoffs, maintainability and other stuff - and not about the hype.

This sounds about right. That being said, many people started using runtime CSS-in-JS because of the hype as well, perhaps not considering performance implications at the time.

100% in favor of moving the discussion from the abstract to the concrete, though. We're planning on running POCs using runtime vs compile time CSS-in-JS libs, looking at things like:

• what the actual perf benefits of using compile-time CSS-in-JS are (and I'd also love to look at potential improvements from following Emotion best practices!)
• how long would the compile step be and can it be an issue for very large applications (like you mentioned)
• how does DX compare? For example, runtime is much more flexible (e.g. dynamic styles based on props just work). Would switching to compile-time make things too verbose/less maintainable using libs such as Linaria?

I'll be happy to report back 🙂

Footnotes

1. For example a page about best practices (and an equivalent blog post elsewhere) and another on performance ↩

[srmagura]

Good thoughts! I think we need to do more to warn users about the potential performance downsides of runtime CSS-in-JS, so I will be brainstorming how this could be represented in our docs. I am also quite interested in the compile-time CSS-in-JS so we could present that as an alternative for performance-sensitive use cases.

[Andarist]

I'm glad that you're optimistic here. This is our main concern with continuing to use Emotion—we've lived happily with the performance implications for years, so were mostly worried about a potential blocker because of a future React version

I certainly can't know the future but it's more than just optimism. The React team very much cares about backward compatibility and I very much doubt they would break the compatibility with a such huge part of the ecosystem.

This is a good point. On a related note, I recently saw new additions to the docs1 with interesting considerations when it comes to best practices for using Emotion.js. There are so many ways to use the library that implementations don't seem to automatically fall into a pit of success.

I very much agree with the pit of success point - that's why I think that Emotion is most useful as a building block for UI/theming libraries and design systems. With those the complexity lives in them and the users only interact with the higher-level API.

A thing that we could consider, for people wanting to continue using Emotion.js but with best practices in mind (for perf but also maintainability, DX etc.), would be to build tooling like ESlint rules to help developers use Emotion.js in the best possible way.

We'd definitely be open for PRs implementing more rules into out ESLint plugin.

This sounds about right. That being said, many people started using runtime CSS-in-JS because of the hype as well, perhaps not considering performance implications at the time.

Totally agree - my hype argument was supposed to apply to both ends of this: how people have hopped on the train and how people want to hop off now.

[srmagura]

Posted a docs PR to make this information more visible to our users as well as to encourage them to think critically about the runtime costs of Emotion. #2869

[penx]

Cross linking to my question here, #2857

I wonder if it would be worth having a package (light version of @emotion/react) that doesn't export (FunctionInterpolation), or any other known bottlenecks?

[hinell]

Any progress on this since that post article on Emtotion.js?

• Why We're Breaking Up with CSS-in-JS [Oct 16, 2022]