Performance-focused forks of styled-components

We're also migrating to vanilla-extract, huge fan of the runtime type-safety ;) The SC forks is to buy us time, Rome wasn't built in a day :)

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.

I ditched Emotion, a very similar solution, since it doesn't work with Next’s App Router, and while looking for a replacement (styleX, Griffel, Vanilla Extract…), I discovered that Styled-Components can be compatible with the App Router.

Why stick with Styled-Components? Because I want to write CSS, not JavaScript objects like most alternatives impose. I understand the typing advantages, but the readability loss just isn’t worth it.

I also use classNames, scoped to each component, it works fine. So why would I replace classNames with JavaScript constants? Again, proper CSS syntax is enough.

I was hoping YakJS would be a complete replacement for Styled-Components, but they don’t support classNames & global styles.