Oh! For me styled-components is the natural way to create web apps... It has been for years. I tried tailwind several times though... Should I learn all those classes to write css? And convince our designers to remake their mockups to fit tailwind styles? Okay, I will try... 

tailwind exploded in trends mainly because people have to google utility classes every time they need to write styles ;) But in general I agree that it's insanely popular now. I switched to it recently too, because it allows to write adaptive styles much faster.

With styled-components I really enjoyed ability to write native css rules in a clean way, and it was very smooth learning curve compared to tailwind. I think styled-components might still be a good choice for critical, reusable UI parts, like UI Kit elements. Tailwind has some issues with extensibility, that's why projects like tw-merge exist, but it has it's downsides and limitations too.

wow, I'm glad I've not overlooked the email in my inbox with this post.
What can I say. CSS-in-JS made a massive change in React's world and FE development overall. And `styled-components` played a significant role in that change.

Thank you for all your efforts and absolute transparency regarding path forward.

I like CSS-in-JS and your library. I even wrote my own implementation of styled-components inspired by your API https://github.com/atellmer/dark/tree/master/packages/styled 
I wish you good luck.

We at digitec galaxus are still embracing CSS-in-JS - and we heavily used styled-components since the beginning of our new frontend stack ~7 years ago. Now we have developed our own open source solution called "next-yak", which can act almost as a drop-in replacement for styled-components: https://yak.js.org/

My opinion from implementing and maintaining a design system for the last 3 years or so: I think it would be ideal for developers to not have to worry about styling at all. It was a goal of ours to enable developers to write frontend code without writing CSS. A design system (or a collection of components akin to a design system) would abstract this away from them. The components you build for the design system can use whatever styling solution you want. In my new project I opted for css-hooks which has been neat.

Regarding your point of "learning all the classes to write CSS", I don't think you need to learn them ahead of time, you can simply look up the docs when you need to find the Tailwind equivalent. (This is a downside of using Tailwind as opposed to css-hooks or something similar.) I believe there are IDE extensions for autocompleting Tailwind classes too.

Lastly regarding your point of "designers making mockups fit tailwind styles", I do not know why that would be at all the approach to take. Designers should make their mockups as they do (e.g. in Figma) and you figure out the Tailwind classes necessary to support it. If you are regularly writing custom CSS every time a new design comes through then you probably don't have a set of standardized components so there's not much of a time loss. You can customize Tailwind pretty extensively.

In the product I am working on, we wrap our React application into Custom HTML Elements. We went all in with Styled-components because it's the only option out there that supports scoping the styles to our shadow roots properly.
So sad this has to go. Styled-components was my favorite option out there. Tailwind like options don't work properly in my context. Any suggestion of alternative?

"The ecosystem in general has largely moved on from css-in-js as a concept"

have they now?

as you can see, Emotion is still on an upward trajectory.

there is room for more than one approach, thankfully. :-)

Yes, @sebastien-belzile we have the alternative - also open source: https://yak.js.org/
Would be great to see more people trying it out, it is basically styled-components but in build-time and on steroids (it's done with SWC and Rust)

Thanks for all the work...

I just started using https://www.restyle.dev. Love it! It's only 5kb, and very similar API to styled-components... Afaik doesn't use React Context either, and works very smoothly for SSR.

I think it needs to be heard around, thus I share here. 

I really enjoyed how styled-component made abstract projects for me and too pity it’s discontinued. I think alternative approaches make sense for developers.

What is your news source for this item? Would this change also effect a CSS-in-JS solution like Emotion?
> The React core team has decided to defacto-deprecate certain APIs like the Context API (not available in RSC with no migration path.)

No its not! Vibe coder use tailwindcss and demand for it increased! other vise styled component and other css in js also growed even old JSS

be creative man we came from days without context api we could handle it, last time i make SSR was 2015 with backbone!
I can think of cookies we can set theme in coockies on the client and in server read the coockies as replacment for context 

here is a quick search result
Client :
```
import Cookies from 'js-cookie';

Cookies.set('theme', 'dark', { expires: 365 });
```

Next Js:
// Not sure how broken context is in ssr maybe we should do it in a custom hook and by pas use context
```
import { cookies } from 'next/headers';

export function YourLayout() {
  const cookieStore = cookies();
  const theme = cookieStore.get('theme')?.value || 'light';

  return <ThemeProvider initialTheme={theme}>...</ThemeProvider>;
}
```

always would be a work around, i can figuret it out should I try?

Oh man, that is terrible news. Styled Components is a tool that enabled the cleanest components architecture in our projects comparet to any other solution BY FAR.

I understand there are some shifts in underlying technologies, but would be great if SC grasped them, even for the cost of making a breaking upgrade. AFAIK there's no proper replacement on the market for what SC provides. There are some similar projects, but each has limitations making them tag behind.

@Evan have you considered joining forces with any of those projects? E.g. Linaria looks very promising - seems like it just needs a touch of experience and motivation to sky-rocket - something that you might provide. I really REALLY think that the composition-promoting DX and simplicity of SC was the best way to handle styling in React apps.

I understand why Evan wrote this but I wanted to say that this is not true, is misleading, and leads to unnecessary FUD that I’ve seen repeated elsewhere.

Context is not only “not deprecated”, but actively relied on by many RSC libraries and frameworks. For example, the Link component itself in the Next.js App Router is implemented using context! Surely saying that context is “de facto deprecated” doesn’t make sense if one of the main RSC framework’s most important components relies on this feature to work at all. And it’s not some kind of a temporary measure — it’s supposed to be relied on. Context is a useful client (“client” includes SSR here) feature, and most RSC code freely composes server and client features.

The problem SC faced is that the scope of environments from which its API gets called has expanded to an environment that doesn’t have context, but its implementation depends on that feature. Again, this isn’t the same as deprecating anything. To draw an analogy, server components are essentially a first-class React alternative to APIs like Remix loaders and old Next.js getInitialProps. No one is complaining that you can’t call a Styled Component from a Remix loader, are they? Nobody is saying that Remix de facto deprecated Styled Components. But that’s a logical conclusion if you take the stance expressed here as correct.

I get the practical frustration, which is that people don’t know or care “which world” they’re in, and they “just” want to call SC APIs as before. Which only works in one of the worlds. And that’s frustrating that SC can’t fix it without fundamentally changing either the API or the implementation. The whole point of RSC is to make that boundary more fluid, but it does unfortunately mean that some generic “component-generating” libraries like SC would pragmatically have to either work in more environments or force people to stay in their old environment (SC works fine within “use client”). In fact, even that is usually not a problem for most RSC libraries (where you can import stuff from a file marked with “use client”), but this wouldn’t work for SC because its API “generates” components rather than just exports them. So SC is unfortunate case where the simple solution doesn’t work, and to preserve its exact API while targeting a new environment, something compile-time would be necessary.

But still, painting this as React “deprecating context” is as wrong as saying Node.js “effectively deprecated DOM”. It is incorrect, and when people repeat it, it causes FUD where people think that their own usage of context (which is not similar to SC’s situation) will break somehow. Whereas, as I’ve shown earlier, typical RSC libraries and frameworks actually rely on context (like Link component in App Router) and it works perfectly fine. 

Exactly. Your team implemented a different flavor of context for RSC which is fine but the original API the library is built upon is not supported for RSC rendering paths. I specified this limitation in the OP, which you are now twisting into something else for... I assume attention, considering this is old news. I was vocal very early about this to try and get it supported, which ended up going nowhere.

At the end of the day, the React core team is going to do whatever, but my comment that the full Context API (as designed and implemented for client and SSR use) is not available in RSC is completely valid. I'm not dumbing down / forking the library to support your arbitrary decisions, that is bad stewardship for the projects that still rely on styled-components.

I'm saying that it is inaccurate to say that context is "de facto deprecated" because it is very much alive, is used widely in the RSC ecosystem, and is not going away. I've seen people repeat the same thing (context "being deprecated") so I commented here because this seems like it could be one of the sources of the misconception, and today was the first time I saw this post. (Concretely, I saw it today because another post has hit HN today, and it links to this post.)

I agree it may be irresponsible to change the public API at this point, and I'm not advocating for that. Context is available in RSC by rendering a client component, and that is what other libraries with a similar (but slightly different) API choose to do. Here is an example someone pointed out to me today — the styled API from Restyle works by passing stuff down to a Client component.

From my understanding, the reason this wouldn't work for SC API is because SC supports inline interpolation of themes like styled.div` ... ${theme => ...}`. The problem is not that you can't read the context on the server (often, this wouldn't matter because you could forward any props to a client component like Restyle does). But it's that you can't pass an inline function like this over the wire.

So I hear your point that the existing API can't be made to work "as is" by extending it to the Server world. But I think it's wrong to say that "context is deprecated" (it's not, and it's actively used in RSC world). I also think it's a bit misleading to explain the situation as "context not working from RSC" when the concrete issue is that you can't pass an inline function down via the network. If you just needed to read context, you could do this by rendering a Client component from a Server component, just like Restyle does. Again, this isn't to say you should do anything, and I'm sorry for the implication if that's how it came across. I just think this framing is misleading to future readers but that's my personal opinion. If I haven't made the case for it convincingly, fine, I won't waste more of your time.