Important context here is that a big chunk of the popularity of styled-components comes from the ease of distributing npm libraries where you could "just import JS" and not worry about how to load the resulting CSS, it "just worked"™.
Some frameworks, like vite and webpack, have generally good support for npm libraries that import CSS files and know how to load them efficiently so userland don't have to deal with it. In the past that was certainly not the case with grunt, gulp, custom webpack where you have no control over how style-loader, MiniCssExtractPlugin, and how any of that was setup.
For React authors things have improved, the ecosystem have pretty much decided on vite being the way to go, and next.js with turbopack align really well, same about parcel 3.
React 19 itself also makes life much easier for framework authors by allowing libraries to render stylesheet tags from anywhere: https://react.dev/reference/react-dom/components/link#linkin...
This works regardless of how a React app is built and rendered (RSC, client components with streaming SSR hydration, regular fully client rendered app with react-dom createRoot which is how Sanity Studio is deployed).
There's even first class APIs for preloading the stylesheet itself, and any fonts it might have: https://react.dev/reference/react-dom/preload#reference
This matters since npm libraries are often specialized. Maybe it's a code syntax highlighter, it might only be rendered in very specific cases and not for the majority of the users of your app. Does it make sense for its chonky CSS to be added to your static global.css and loaded up front?
What about a charts library, maybe it's only used by your dashboard, seen by authenticated users, and not your marketing website overall?
styled-components worked really well in these cases, as it supported regular JS lazy loading techniques and CSS weren't inserted until it was needed.
While it was possible to achieve these same benefits in an app that you have control over the bundling and chunking, the challenge library authors face is that you don't have any control over that.
With React 19, this changes, though it'll take time before 19 is the baseline for most devs, it's currently 18.
TL;DR I agree with you this statement sounds silly for app builders. For framework authors it's a bit too tongue in cheek IMO.
I agree, the end game should be to get rid of styled-components. At Sanity we are in fact in the process of moving to https://vanilla-extract.style/
At the same time, with thousands of styled components already in use in production, it'll take a while until they're all refactored. And so it makes sense for us to make the best of styled-components and make it as fast as it can be on the React 18 and 19 baselines, to buy us time for the larger refactor that completely solves it.
TL;DR it's better to never insert CSS at runtime and only link to a cached external stylesheet. If you have brownfield code that inserts CSS at runtime that should be refactored. Until they are refactored, they should insert CSS at runtime in the best possible way (even though it's never truly good or fast).
When you start out on a small app the slowness doesn't stick out anywhere. App keeps growing until one day it becomes very obvious in perf profiles. At that stage it's difficult to refactor out of it to another system, as a lot of the brownfield might've drifted into relying on techniques that can only be used when inserting CSS at runtime:
- generate `@media` query selectors with ranges based on JS state and nesting.
- calc background color that pass a11y contrast ratio tests based on dynamic foreground colors (for example the color palette generated from an image asset)
Even so, it takes time to refactor thousands of files.
>It always was. You decided to make it slow and were fine with it, not sure why that's suddenly unacceptable.
The decision might've been made years before you joined the organization, and you're now left with that decision and have to plan for what to do about it.
Some more context on why the PR doesn't make a dent in the existing benchmark suite:
- existing benchmarking suite uses react 17 as the baseline, the new useInsertionEffect hook requires react 18. Additionally, the new hook plays a role in concurrent render scenarios also introduced by react 18, which the current benchmark wasn't testing. We made a new benchmark on react 19 in a worst case scenario that the new hook is designed to mitigate, we shared a recording of the before and after here https://github.com/styled-components/styled-components/pull/... with before and after links.
= react 18 and later and its concurrent render mode uses cooperative scheduling techniques and tries to yield to the main thread and have your application stay responsive. You won't see a difference in flamecharts in the same way as typical perf issues, since the problem isn't that something is blocking main thread render and causing locks or fps drops necessarily. The problem is that background render takes much longer and risk hitting the deadline where it becomes sync.
- it's notoriously difficult to write benchmarks that tap into concurrent mode behaviors in react, our own benchmark had to write css that escape the default styled components scoped selectors in order to get consistent bench results.
- if it's the same speed as before in the react 17 benchmarks it means the new behavior and its fallback when outside of react 18 is working as intended and did not cause a regression. It's not reasonable for it to be significantly faster in all cases, the purpose is to prevent it from being extremely slow in Suspense, React.lazy, useTransition, useDeferredValue, <Activity mode="hidden">, startTransition, and other concurrent mode cases.
I've been around since the jQuery days ;)
Important context here is that a big chunk of the popularity of styled-components comes from the ease of distributing npm libraries where you could "just import JS" and not worry about how to load the resulting CSS, it "just worked"™.
Some frameworks, like vite and webpack, have generally good support for npm libraries that import CSS files and know how to load them efficiently so userland don't have to deal with it. In the past that was certainly not the case with grunt, gulp, custom webpack where you have no control over how style-loader, MiniCssExtractPlugin, and how any of that was setup.
For React authors things have improved, the ecosystem have pretty much decided on vite being the way to go, and next.js with turbopack align really well, same about parcel 3. React 19 itself also makes life much easier for framework authors by allowing libraries to render stylesheet tags from anywhere: https://react.dev/reference/react-dom/components/link#linkin... This works regardless of how a React app is built and rendered (RSC, client components with streaming SSR hydration, regular fully client rendered app with react-dom createRoot which is how Sanity Studio is deployed). There's even first class APIs for preloading the stylesheet itself, and any fonts it might have: https://react.dev/reference/react-dom/preload#reference
This matters since npm libraries are often specialized. Maybe it's a code syntax highlighter, it might only be rendered in very specific cases and not for the majority of the users of your app. Does it make sense for its chonky CSS to be added to your static global.css and loaded up front? What about a charts library, maybe it's only used by your dashboard, seen by authenticated users, and not your marketing website overall? styled-components worked really well in these cases, as it supported regular JS lazy loading techniques and CSS weren't inserted until it was needed. While it was possible to achieve these same benefits in an app that you have control over the bundling and chunking, the challenge library authors face is that you don't have any control over that.
With React 19, this changes, though it'll take time before 19 is the baseline for most devs, it's currently 18.
TL;DR I agree with you this statement sounds silly for app builders. For framework authors it's a bit too tongue in cheek IMO.