Rethinking React Styling for the RSC Era

Hey everyone, I hope that you all are having an amazing time so far at React Advanced. Welcome to Rethinking React Styling for the RSC Era. I'm Bree, a senior developer advocate at Atlassian, and I'm so excited to be here with you all today. I'm always really curious, so let me know in the chat below what your favorite method of styling React applications is, because I don't know if you all have been in the group chats lately, but styling React components has gotten just a little bit spicy. React 19 has dropped, Tailwind has reinvented itself, native CSS is in its glow-up era, and even the core maintainer of styled components said maybe it's time to move on.

So today we're unpacking what's really going on with styling in 2025, what holds up, what's falling apart, and how to choose a styling approach that does not have you crying in your code reviews like I used to be. It feels like every couple of years we have to have the talk, right? We get really comfortable with tools, we pick our favorite methods, we have our workflows that are feeling really nice and really smooth, and then something comes along and flips the whole table over. Now, in the past few years, that something has been React Server components, but it doesn't really feel like it's just flipped the table. It kind of feels like it's redefined how we actually should be styling our applications.

For the next 20 minutes, we're going to untangle this mess and talk about how to make smart, future-proof decisions for styling your projects. Because in late 2025, there's a new litmus test for every styling library, and honestly, it's pretty simple. The question is, can you generate static zero runtime CSS at build time? If your styling solution needs a JavaScript runtime on the client to inject files, it's fundamentally at odds with the server-first feature that React is building. So this single requirement has honestly caused a really big shift in our ecosystem. It's forced some migrations, it's elevated a new class of contenders. So today, we're going to talk about the three dominant philosophies, and we're going to put them to the test.

We're going to talk about scope CSS with CSS modules, utility-first frameworks with Tailwind, and also the new compile-time CSS and JS. Let's dive in.

First, we've got to acknowledge the elephant in the room, the paradigm that defined an era of React development, runtime, CSS, and JS. Earlier this year, the maintainer of styled components officially announced that it was in maintenance mode and that they no longer recommended it for new projects. This wasn't really a surprise to anyone, but it did feel like a significant event.

So why the incompatibility? It all comes down to one simple fact. Server components cannot access React context. If we think for a quick second about how frameworks like styled components or how emotion works, you basically wrap your app inside of a theme provider, which uses the context to pass down your theme down the tree. Then, in your component, the library uses that theme context plus a JavaScript runtime to dynamically generate and inject a style tag into the document head.

So the community reaction to this news has been a little bit of sadness, a lot of frustration, especially for those with large legacy code bases, and a collective sense of good riddance from a lot of people as well. This has kicked off what I feel like is a little bit of a great migration. Some teams are trying to figure out what their exit strategy is going to be. It's not just a technical migration at this point; it's also a philosophical one about how we actually want to approach building software in 2025.

They can't run the JavaScript needed to inject the styles. To make the style components work, you have to wrap it in a use client boundary, which ops the entire part of the tree out of the RSC model, which kind of defeats the purpose. So the community reaction to this news has been a little bit of sadness, a lot of frustration, especially for those with large legacy code bases, and a collective sense of good riddance from a lot of people as well.

So this has kicked off what I feel like is a little bit of a great migration. Some teams are trying to figure out what their exit strategy is going to be. And as they leave the world of runtime styling, they're moving to two very different but equally valid directions. It's not really just a technical migration at this point. It's also a philosophical one about how we actually want to approach building software in 2025.

One of the options is returning to native CSS because in 2025, CSS as a standalone is incredibly powerful. In previous years, we've relied on things like preprocessors, like SAS for features that are now standard in almost every major browser. We have things like CSS nesting, which is fully supported, allowing us to write cleaner and more organized styles without a preprocessor. We have new pseudo classes like the has, which was a long-awaited one, and the is, which gives us unprecedented control to simplify complex styles.

And the platform is always evolving faster now more than ever, with new capabilities like scroll driven animations and container queries, and basically things that give us more access to native styling controls. So this is actually where CSS modules tends to shine. At its core, it's a really simple build time tool that solves the biggest problem with CSS at scale, which is the global namespace. It takes a regular CSS file and makes every class name locally scoped by default, preventing style collisions. So there's no new syntax to learn. If you already know CSS, then you know CSS modules. And for many of us, this feels like a safe, future proof bet that avoids vendor lock ins.

Now on the other side, we have people who are going for the programmatic productivity. And these are folks who are all in on tools like Tailwind CSS. Now at a high level, Tailwind is a utility first framework. So instead of writing custom CSS, you basically build your designs by composing like single use utility classes directly inside of your markup. These are going to be classes like Flex for your background and for your padding as well. People tend to gravitate towards it for a variety of different reasons, but we'll just talk about a couple super quick. The first one is its speed. You can prototype and build really complex UIs incredibly fast without ever having to leave your JSX or inventing your own new class names. The second thing is consistency. It enforces the design system through its pre-defined scales for color, for spacing, for typography, which is a really big for larger teams and collaboration as well. And most importantly for the RSC era, it has a zero runtime cost. So this is a build tool that is going to scan your files and generate a highly optimized CSS file that only contains the styles that you're actually going to use.

So we have these two opposing philosophies. We have the simplicity of native CSS versus the productivity of a utility first framework, plus a new wave of tools that are trying to give us both. So how do they actually hold up? All right, now that we've laid the foundation and seen how the styling landscape is starting to shift, let's actually put these tools into practice and see how they hold up. Our test case is a live product card. It's a realistic hybrid component. The container image and title are all rendered on the server as server components, but the add to cart button needs state. So it is an interactive client component. This server client boundary is where old styling habits tend to break down. We're going to evaluate our three main approaches across four critical demands of a modern server first architecture. Let's start with CSS and JS and see how it might fail some of the tests that we currently have. The first one is server side rendering and hydration.

The guiding question is going to be, how does this generate the initial HTML and what happens on the client? With runtime libraries, the server has to do a lot of work to extract the styles and inject them. But the real problem is that its entire theming and styling model is built on React context. And as we established previously, React server components do not have a way to access the context. So the only way to make styled components work is to again wrap it in that use client directive, which opts you out of the whole RSC model. So our first test is going to be a fail.

What about with streaming UI? So if this card is streamed in after an initial load, do we get the flash of unstyled content? The answer is yes, and it is one of the biggest weaknesses of CSS and JS. So the streamed HTML for the card can arrive and render in the browser before the JavaScript contains the styling logic that has been downloaded and parsed and executed. So this means that there could be a noticeable delay when the component is on screen and it is completely unstyled and it can create a jarring user experience.

Let's talk about scalable theming. The question is, how do we apply a sale theme, for instance, to our card, ensuring that both the server and the client parts are styled consistently. So the client rendered button can access the styles, but the server part can't. This is going to make it really difficult to maintain theme consistency across server and client boundaries. And let's talk about runtime performance as well. What's the cost of actually running this on the user's device? So the cost can be pretty significant. You have to ship a JavaScript runtime to the client, which bloats the bundle size. This means that there will likely be a delay in time to interactive. We have concrete proof of this cost because there is actually a recent fork of the style components library called style components last resort, which actually implemented react 18 optimizations that the original library never did. And it actually yielded a 40% faster initial render for teams like linear. This was a really massive overhead. And it's really interesting to see that they were able to optimize it.

Now let's talk about Tailwind CSS. For streaming UI, this is actually a major strength. The static CSS file containing all the necessary utilities is loaded up front with the initial page shell. So when the page is streamed in and our card arrives, the browser already has access to the CSS rules for every class name in the markup. So the component renders instantly and correctly, fully styled.

In terms of scalable theming, the modern standard for theming is native CSS properties and Tailwind version four has the new theme directive that compiles your design tokens directly into CSS variables. Because this is a native browser feature, they cascade normally and are accessible to all HTML, whether they're rendered on the server or the client. So theming across the server client boundary becomes a lot more seamless.

In terms of runtime performance, the client side cost is basically zero. All of the heavy lifting, the parsing the code, generating the CSS and optimizing it happens at build time. So the browser just gets a static CSS file and the HTML with the class names, which is the most performant way to render styles. So architecturally, this can be a really good choice, but I also don't want to ignore a lot of the vocal criticism that it receives.

I think one of the most famous critiques is the div soup commentary that your JSX can get really verbose or start to feel a little bit cluttered and almost like a regression to inline styles. So there's also beyond that, the class name soup, there is a philosophical pushback too. And there's a strong sentiment that using Tailwind encourages developers to unlearn CSS trading platform fundamentals for a proprietary abstraction. And that abstraction leads to concerns about things like vendor lock in. So when a tool is this deeply embedded in your markup, migrating away from it for whatever reason if you have to down the road is going to be a massive undertaking.

So how do thousands of teams go about using Tailwind at scale to reconcile this? They solve this with the most immediate pain point, the cluttered markup with a more disciplined abstraction. So the modern and scalable pattern is not to use the apply directive, but it's instead to embrace the component-based architecture and use dedicated libraries, things like Tailwind variants or class names that provide you type safety, a structured API for defining your component variants that map to specific combinations of utility classes. This works because you get the power of utilities for implementation, but the application code also becomes more clean and declarative as well.

Now, while this doesn't resolve the philosophical debate about whether it forces developers to unlearn good CSS habits or maybe not learn them at all, if developers are starting with Tailwind, it does provide a robust production-proven pattern for managing its complexity. Now let's talk about native CSS and CSS modules. Something that I have been enjoying a lot recently, and I feel like it could potentially be a modern successor, is Panda CSS. So this is, I think, the best of both worlds promise. It is the developer experience of CSS and JS with the performance of static CSS. So let's run the test that we've talked about a little bit earlier. In terms of SSR and hydration, Panda is also a build-time tool and it uses static analysis to parse your JavaScript or your TypeScript and then find style definitions in the style calls or the JSX props and extracts them into a static CSS file.

So the initial component code is transformed to reference the generated class names. This is basically the same principle as Tailwind, just with a different authoring input. So I feel like this would pass our test. For streaming UI, same as Tailwind, it generates a static CSS file that is loaded up front so that the streamed components render instantly and are fully styled.

In terms of scalable theming, Panda's type safe token system is defined in a Panda.config.ts, a little bit similar to a Tailwind config, if you are familiar with that. And it also generates custom CSS properties. So this means that it has the same critical benefit that theming works seamlessly across server and client boundaries because it is a native platform feature. And in terms of runtime performance, again, this is a zero cost to us. So Panda passes every test for the same architectural reasons as Tailwind. And it proves that the choice between modern solutions isn't exactly always about performance trade-offs, but it also has to do a lot with authoring experience and what you and your team prefer.

It also has a very powerful Variants API, which they call recipes, that are built right in. So this gives you the same structured styling that you might get from something like Tailwind Variants, but a first party and core feature of Panda as a library itself. This makes it kind of a compelling or maybe all-in-one solution for teams who want to write their styles in TypeScript along with their component logic. Our stress test made it clear that the era of runtime styling for server-first applications is over. We have a new field of like performant, excellent build time solutions, and now it is time for every developer's favorite answer to the question, which one should I use to build?

But that would be a cop out to just leave it there. The choice is no longer necessarily about performance trade-offs, and it's really more so about your project's specific needs and what your team's philosophy is. So let's put it all together. This is one of the decision frameworks for 2025. First and foremost, let's look at that top row, RSC performance. The key takeaway is the performance is not necessarily our biggest concern now. And the debate is more about the developer experience and the project fit. So let's talk about what people actually like and dislike about each one.

With Tailwind, people love its unmatched speed and productivity. You can build your UIs really fast, and it enforces a consistent design system across your team. So the ecosystem is also really, really big. But on the flip side, people hate the class name soup and the clutter that it can give with your JSX. And there are real philosophical concerns about unlearning CSS and the long-term vendor lock-in that it can create. And then we have Panda CSS, which is representing our compile time camp. What people love about it is that it delivers the experience of CSS and JS with code-located styles, powerful variants, but without a runtime cost.

Type safety is also a really big win for maintainability. But the biggest dislike is that it's another tool. It adds setup complexity and a learning curve to your project. And the ecosystem is still growing fast, but it is also still newer. And finally, CSS modules. People love its simplicity. It's just CSS. And that's it. You get clean separation of concerns, and there's absolutely no vendor lock-in there, which feels very safe in a fast-moving ecosystem. The dislikes, obviously, it can feel really clunky and very verbose for dynamic styling. The theming lacks the robust type safety of the other solutions, and it's definitely slower in terms of rapid prototyping.

The theming lacks the robust type safety of the other solutions, and it's definitely slower in terms of rapid prototyping. So that brings us to the final and most practical question, what's the ideal project, really, for each one? To put it really quick, choose Tailwind if you are looking for an MVP or any project where your velocity is an absolute priority. You may want to reach for something like Pandas CSS if you're building a design system with complex component libraries or your team is culturally committed to the CSS and JS authoring style, or choose CSS modules for projects where long-term stability and minimizing dependencies are a lot more important than your initial development.

We've pretty much moved decisively to a world where styling logic is now happening or being resolved at build time. So the choice for a new project in 2025 more so boils down to a philosophical one. Do you prefer utility-first HTML-centric workflows of things like Tailwind? Do you prefer the type-safe JavaScript style tools like Pandas CSS? Or do you really just want the foundational simplicity of CSS modules? At the end of the day, styling in React isn't just a technical decision, it's a product decision, it's a team decision, and it is most importantly a you decision.

So whatever you choose, make sure that it serves your team, make sure that it serves your apps, and where front end is actually headed. That's how we build apps that feel good to maintain, scale well with our teams, and that still look really fricking good. So if you want to know more about the current state of CSS and what people are really using today, I highly, highly, highly recommend that you check out the State of CSS 2025 survey. I've been going through the past couple of days and comparing it against the results from last year, and it's just so interesting how much can change in a little bit of time. And with that, I want to say thank you so much for being here. Thank you to the React Advanced team for having me. I will be in the chat and in the Discord, so I would love to hang out and talk a little bit more about these different styling solutions and understand what you all are currently using. I will go ahead and leave a QR code where we can connect, and also a little bit more information about some of the things in the styling world that I have seen recently that may be able to help you a lot as well. Thank you so much.