Ask three good frontend developers how to style a React app and you will get three confident, contradictory answers. Tailwind, says one. CSS-in-JS, says another. Just write CSS, says the third. Each is right for some projects and wrong for others, and the tribal certainty around each option hides the fact that this is a trade-off, not a truth.
The choice matters because styling is not a detail you can swap out later. It threads through every component, shapes how your team works, and affects how fast your app loads. Get it right and styling stays invisible. Get it wrong and you spend the next year fighting your own decision. This is the honest 2026 comparison: what each approach actually is, where it wins, where it hurts, and how to choose.
Tailwind vs CSS-in-JS vs Plain CSS at a Glance
| Dimension | Tailwind | CSS-in-JS | Plain CSS / Modules | |---|---|---|---| | Build speed | Very fast | Fast | Moderate | | Runtime cost | Zero | Zero (build-time) to notable (runtime) | Zero | | Dynamic prop-based styling | Awkward | Excellent | Manual | | Markup readability | Busy (long class strings) | Clean | Clean | | Consistency by default | High (tokens built in) | Depends on setup | Depends on discipline | | Learning curve | Moderate | Moderate | Low | | Long-term dependency risk | Framework lock-in | Library lock-in | None | | Bundle size overhead | 0 (purged) | 15-30KB (runtime) or 0 (zero-runtime) | 0 | | SSR complexity | None | Moderate to significant | None | | Component-scoped by default | Yes (utility classes) | Yes | Yes (Modules) or No (global) | | Best for | Fast product teams | Highly dynamic UIs | Long-lived, low-churn apps | | Winner in 2026 for MVPs | Usually | Rarely | Sometimes |
Read on for the detail. The short version: Tailwind wins on velocity for most product teams, plain CSS is under-rated for long-lived codebases, and CSS-in-JS is a niche answer for state-heavy UIs but only in its zero-runtime form.
The Three Approaches, Briefly
Plain CSS covers writing actual stylesheets, whether global CSS, CSS Modules (scoped per component), or modern CSS with custom properties and nesting. It is the platform. No build-time abstraction, no runtime cost, just the browser doing what it does.
Tailwind is a utility-first framework. Instead of writing CSS, you compose pre-defined utility classes directly in your markup: flex items-center gap-4 p-6 rounded-lg. The styling lives in the component, expressed as class names, and a build step strips everything you do not use.
CSS-in-JS covers libraries like styled-components and Emotion that let you write CSS inside JavaScript, scoped to components and able to react to props. Styling becomes part of the component logic. The category has shifted in recent years toward zero-runtime options precisely because the runtime versions carried a performance cost.
Tailwind: Fast to Build, Divisive to Read
Tailwind's core strength is velocity. You style as you build, in the same file, without inventing class names or switching context to a stylesheet. For a team moving fast, this is a real productivity gain, and it compounds because the constraints of a design token system are baked in. Spacing, colours, and sizes come from a fixed scale, so the output stays consistent almost by default.
Performance is excellent. Because unused utilities are purged at build time, the shipped CSS is small and there is zero runtime cost. What arrives in the browser is plain CSS. On a large app this is a meaningful advantage over runtime CSS-in-JS. It is also why Tailwind performs well on the same metrics that surface in why your React app is slow.
Consistency comes free. The utility scale (spacing, colour, typography) removes the constant micro-decisions about "should this be 12 or 16 pixels" that plague plain CSS codebases. Everyone builds from the same tokens, so the design stays coherent even as many people contribute.
The cost is readability and the markup. Components accumulate long strings of utility classes, and developers who dislike Tailwind usually dislike exactly this: the styling is verbose, the markup is busy, and reading a component means parsing a wall of classes. The counter is that everything is in one place and there is no hunting through stylesheets, but it is a genuine trade and teams feel it differently.
Where Tailwind starts to hurt. Very complex state-driven styling gets ugly fast. Long conditional class strings, dynamic classes constructed from JS variables, and heavy animations often push you into escape hatches (custom CSS files, arbitrary values, cn() utility) that dilute the "everything is a utility" model.
Tailwind fits teams that value build speed and consistency, that are comfortable with utility classes, and that want styling co-located with markup. It is a strong default for product teams shipping quickly, and it composes cleanly with a component library, which is why it pairs naturally with a design system built from scratch in React.
CSS-in-JS: Powerful, With a Performance Asterisk
CSS-in-JS shines when styling needs to be dynamic. Because styles live in JavaScript and can read props, you express "this button is this colour when active, that size when large" directly and naturally. For highly interactive, state-driven interfaces, this expressiveness is a real benefit, and the scoping is automatic, so you never fight global namespace collisions.
Composability is strong. You can build higher-order styled components, extend one component from another, and pass style variants as props in ways that feel native. For component libraries with lots of variants, this is genuinely nice.
Theming is first-class. Multi-theme apps (light/dark, brand-per-tenant) work naturally in CSS-in-JS because themes are just JavaScript objects passed via context. Doing the same in Tailwind or plain CSS is possible but more mechanical.
The historic problem is runtime cost. Traditional runtime CSS-in-JS generates styles in the browser as components render, which adds work on every render and can hurt performance on large or frequently updating apps. In server-rendered React and Next.js, it also complicates streaming and has been a known source of friction.
The ecosystem responded with zero-runtime CSS-in-JS libraries (Panda CSS, Vanilla Extract, Linaria, StyleX) that extract styles at build time and remove the runtime penalty. This is where serious CSS-in-JS usage has moved in 2026. If you go CSS-in-JS, go zero-runtime.
Where CSS-in-JS starts to hurt. Bundle size (for runtime versions), server-render complexity, learning curve for junior engineers, and the fact that the ecosystem keeps churning. Libraries popular in 2022 are dead in 2026. This is real dependency risk.
CSS-in-JS fits teams that want styling tightly coupled to component logic, that have genuinely dynamic styling needs, and that are willing to choose a zero-runtime solution to avoid the performance tax. It is less appealing if your styling is mostly static, because you pay in complexity for flexibility you are not using. It also interacts with your rendering strategy, so it is worth deciding alongside how server and client components split the work in Next.js.
Plain CSS: Underrated, Especially Now
Plain CSS keeps getting written off and keeps being the right answer more often than its reputation suggests, particularly because the language itself has improved dramatically. Native nesting, custom properties (CSS variables), container queries, cascade layers, and the :has() selector mean modern CSS does things that used to require a preprocessor or a library. CSS Modules give you the component-scoping that was CSS-in-JS's main selling point, without any JavaScript runtime.
The strengths are simplicity and longevity. There is no framework to learn, no build-time magic beyond bundling, no dependency to break on the next major version, and zero runtime cost. Anyone who knows CSS can read it, and CSS is not going anywhere. For a long-lived codebase, the absence of a styling dependency is a feature, not a gap.
Modern CSS is a real upgrade. Custom properties give you theming without JavaScript. Container queries give you responsive components that respond to their container, not the viewport. :has() unlocks patterns that used to require JavaScript. If you have not looked at CSS in five years, it is a different language.
CSS Modules solve the naming problem. The classic pain of plain CSS was global namespace collisions and name-hunting. CSS Modules scope class names automatically per component and give you locally-scoped animations. You write CSS. You import it. The names never collide.
The weaknesses are the ones Tailwind and CSS-in-JS were invented to solve: naming things is hard, keeping styles consistent takes discipline, and without a token system it is easy to drift into fifty slightly different shades of grey. Plain CSS gives you the least structure, which is freedom if your team has discipline and rope if it does not. Good conventions matter more here than anywhere, the same conventions that keep CSS decisions maintainable across a growing site.
Where plain CSS starts to hurt. No opinionated system for design tokens (you have to build one). No enforced consistency (relies on team discipline). Slower initial styling velocity vs Tailwind.
Plain CSS with CSS Modules fits teams that value simplicity and low dependencies, that have the discipline to maintain their own conventions, and that are building something meant to last with minimal churn.
Performance in the Real World
It is worth being precise about performance, because it is where a lot of the tribal argument happens and where the stakes are real on large apps.
| Approach | CSS delivered | Runtime cost | SSR complexity | Bundle impact | |---|---|---|---|---| | Tailwind | Purged static CSS | Zero | None | Tiny (only used classes ship) | | Plain CSS / Modules | Static CSS | Zero | None | Only the CSS you wrote | | Zero-runtime CSS-in-JS | Static CSS (extracted at build) | Zero | Minimal | Small | | Runtime CSS-in-JS | Injected at render | Notable (per render) | Significant (server rendering complexity) | 15-30KB library + inline styles |
The upshot in 2026: Tailwind and plain CSS both ship as static CSS with zero runtime cost. Zero-runtime CSS-in-JS gets you the same performance profile with the ergonomics of runtime CSS-in-JS. Runtime CSS-in-JS is a tax you no longer have to pay, so do not pay it by accident.
For apps where performance really matters, think large tables, real-time dashboards, or complex forms, the runtime overhead of traditional CSS-in-JS is measurable on Interaction to Next Paint (INP) metrics. This is exactly the kind of subtle performance problem covered in why your React app is slow (and how to fix it without a rewrite).
Bundle Size Comparison
For a typical 200-component app:
| Approach | Bundle overhead | |---|---| | Tailwind (purged) | 8-15 KB CSS | | Plain CSS Modules | 10-30 KB CSS (varies by discipline) | | Vanilla Extract (zero-runtime CSS-in-JS) | 10-20 KB CSS + minimal JS | | Panda CSS (zero-runtime CSS-in-JS) | 10-20 KB CSS + ~5 KB JS | | Emotion (runtime CSS-in-JS) | 25-45 KB JS + inline styles | | Styled-components (runtime CSS-in-JS) | 30-50 KB JS + inline styles |
The runtime CSS-in-JS overhead used to be justified by ergonomics. In 2026, zero-runtime options give you the same ergonomics without the tax, so the runtime versions are hard to justify for new projects.
What About Mixing Approaches?
A fair question is whether you have to pick one at all. In practice, most codebases lean heavily on a primary approach and use a second sparingly, and that is fine. A Tailwind project might drop into a plain CSS file for one genuinely complex component that would be unreadable as utility classes. A CSS Modules project might reach for a small amount of inline dynamic styling where a value is truly computed at runtime. Pragmatic mixing at the edges is normal.
What is not fine is having no primary approach. A codebase where some components use Tailwind, some use styled-components, and some use loose global CSS, with no rule about which and when, is the worst of all worlds. New developers cannot predict how any given component is styled, changes are risky because the patterns are inconsistent, and the whole thing drifts toward entropy. The cost is not the mixing itself, it is the absence of a decision.
So the rule is simple: pick one primary approach deliberately, document it, and treat any deviation as a conscious exception with a reason, not a default anyone can reach for. A consistent codebase with an imperfect styling choice beats an inconsistent codebase with three excellent ones, because consistency is what lets a team move quickly without stepping on each other. This is the same discipline that separates codebases that stay maintainable from those that quietly rot, regardless of which tool sits underneath. See the frontend best practices checklist for the broader set of consistency rules that matter.
How Each Choice Interacts With Next.js
Modern Next.js (App Router with React Server Components) puts pressure on styling choices in ways older React SPAs did not.
Tailwind: works perfectly. Static CSS ships during SSR, no client-server hydration mismatch, no runtime style generation. Recommended for most new Next.js apps.
Plain CSS / CSS Modules: works perfectly. Same story, ships as static CSS, no server-side complexity.
Zero-runtime CSS-in-JS: works well. Builds static CSS at build time. Panda CSS and Vanilla Extract both have first-class Next.js support.
Runtime CSS-in-JS: works but with real complexity. Styles must be generated on the server, inlined into the initial HTML, then not double-rendered on the client. Emotion and styled-components have Next.js integration guides, but the setup is fiddly and the performance is worse than the alternatives. Not recommended for new Next.js apps.
For the wider set of Next.js architectural decisions that interact with this, see Next.js project structure and Next.js data fetching strategy.
Framework Compatibility Matrix
| Framework | Tailwind | Plain CSS/Modules | Zero-runtime CSS-in-JS | Runtime CSS-in-JS | |---|---|---|---|---| | Next.js (App Router) | Excellent | Excellent | Excellent | Works, complex | | Next.js (Pages Router) | Excellent | Excellent | Good | Works, complex | | Vite + React | Excellent | Excellent | Good | Fine | | Remix | Excellent | Excellent | Good | Works, complex | | React Native (Web + Native) | Via NativeWind | Limited | Limited | Fine | | Astro | Excellent | Excellent | Fine | Fine |
If your team ships across React Native + Web, Tailwind (via NativeWind) or Emotion are the most portable options.
Team-Fit Considerations
The tool that fits your team beats the tool that fits the article. Consider:
Junior-heavy teams: Tailwind or plain CSS. Both are easier to onboard than CSS-in-JS ecosystems that churn. Tailwind's constraints prevent junior-level "creativity" that produces inconsistent design.
Senior-heavy teams: any of the three. Senior engineers thrive with the freedom of plain CSS and its modern features. Senior product teams tend to pick Tailwind for velocity.
Design-system-first teams: Tailwind or zero-runtime CSS-in-JS (Panda). Both are designed around a design token system. Plain CSS requires you to build the token system yourself.
Multi-team codebases (10+ engineers): Tailwind. The consistency-by-default matters more as the codebase gets more contributors.
One-person projects: whichever the developer likes. Consistency-by-default matters less when one person holds the whole codebase.
How to Actually Choose
Start with your team, not the technology. A team that already thinks in utilities and ships fast will be productive in Tailwind on day one. A team that values the platform and long-term simplicity will be happier in CSS Modules. A team building genuinely dynamic, state-heavy interfaces has the strongest case for zero-runtime CSS-in-JS.
Then weigh the app. A content-heavy or long-lived product with mostly static styling leans toward plain CSS or Tailwind. A highly interactive application with lots of state-driven styling leans toward CSS-in-JS. A fast-moving product team optimising for shipping velocity and consistency leans toward Tailwind, which is why it has become the common default for exactly that profile.
The default we recommend in 2026: Tailwind for most product teams. Plain CSS with Modules for long-lived, low-churn codebases where dependency minimisation is a real value. Zero-runtime CSS-in-JS (Panda, Vanilla Extract) for the specific case of highly-dynamic UIs or multi-theme products where the ergonomics justify the extra complexity.
Do NOT in 2026: pick a new project on runtime CSS-in-JS. The performance cost and SSR complexity are no longer justified when zero-runtime options exist.
Do NOT in 2026: use unscoped global CSS as your primary approach in any codebase with more than one contributor. Name collisions and specificity wars are still real problems that CSS Modules or Tailwind eliminate for free.
A Decision Framework: Answer These Five Questions
- How dynamic is your styling? Mostly static → Tailwind or plain CSS. Very dynamic → zero-runtime CSS-in-JS.
- How long do you expect this codebase to live? 5+ years → plain CSS or Tailwind. Under 2 years → any is fine.
- How large is the team? 10+ engineers → Tailwind for enforced consistency. Under 5 → any.
- What is the performance sensitivity? High → Tailwind or plain CSS. Moderate → any zero-runtime option.
- Is your framework SSR-heavy (Next.js App Router)? Yes → avoid runtime CSS-in-JS.
Match your answers to the recommendations above and the choice usually falls out clearly.
Frequently Asked Questions
What is the best styling approach for a Next.js app in 2026? Tailwind for most product apps. Plain CSS with Modules for long-lived apps where you want minimal dependencies. Zero-runtime CSS-in-JS (Panda CSS, Vanilla Extract) for highly dynamic UIs. Avoid runtime CSS-in-JS in new Next.js projects.
Is Tailwind faster than CSS-in-JS? Yes for runtime CSS-in-JS (Tailwind has zero runtime cost). Roughly equal for zero-runtime CSS-in-JS. Both approaches ship static CSS.
Is Tailwind bad for accessibility? No. Tailwind is neutral on accessibility, the utilities themselves do not affect accessibility. Bad Tailwind code can be inaccessible, the same as bad CSS-in-JS or bad plain CSS.
Does Tailwind produce a larger CSS bundle? No. Tailwind's purge step strips unused utilities. A typical Tailwind app ships 8-15 KB of CSS, less than a hand-rolled CSS codebase of the same size.
Is CSS-in-JS still worth using in 2026? Yes, in the zero-runtime form, and specifically for highly dynamic UIs or multi-theme apps. Runtime CSS-in-JS is no longer worth the performance cost given the alternatives.
Should I use CSS Modules or Tailwind? Both are excellent. Tailwind wins on velocity and consistency-by-default. CSS Modules win on simplicity, longevity, and no framework dependency. Team preference matters as much as either strength.
What is the difference between Tailwind and Emotion? Tailwind is utility-first (pre-defined class names). Emotion is CSS-in-JS (write CSS in JavaScript). Different mental models entirely.
Is plain CSS coming back in 2026? Yes, meaningfully. Native nesting, custom properties, container queries, and :has() closed the gap that preprocessors and CSS-in-JS were built to fill.
Can I switch from CSS-in-JS to Tailwind mid-project? Yes, but it is a real migration. Plan for 1-2 weeks per 100 components, and expect design regressions along the way. Do it because you have decided the future is Tailwind, not because Tailwind is trending.
Does Tailwind work for design systems? Excellent. Tailwind was built around the design token concept. See how to build a design system from scratch in React for the design system pattern that pairs well with it.
What about Sass or PostCSS? Sass is still valid for plain CSS teams who want mixins and better syntax. PostCSS is the build layer that Tailwind and most modern CSS setups use under the hood. Neither competes with the three approaches in this comparison, they augment plain CSS.
How much does styling choice actually affect performance? On small apps, barely. On large apps, meaningfully. Runtime CSS-in-JS on a large app can add 100+ ms to Interaction to Next Paint. Static CSS approaches (Tailwind, plain, zero-runtime CSS-in-JS) do not have this cost.
What is the newest CSS feature I should be using in 2026? :has() (parent selector), container queries, cascade layers, view transitions API (for animated route changes), scroll-linked animations. Modern CSS is a real upgrade.
The Bottom Line
There is no universally correct answer, and anyone who tells you otherwise is describing their preference as a law. What there is, is a right answer for your team, your app, and your time horizon. Decide it deliberately, write down the convention, and hold to it, because the discipline of a consistent approach matters more than which of the three you pick.
For most product teams in 2026, we recommend Tailwind. For long-lived low-churn codebases, plain CSS with Modules is under-rated. Zero-runtime CSS-in-JS is a niche but valid choice for highly dynamic UIs. Runtime CSS-in-JS is a tax that no longer needs paying.
Whatever you choose, the decision-making discipline is the same: pick one primary approach, document it, and let deviations be exceptions with reasons.
Related Reading
- React Frontend Architecture That Scales Past 50 Components
- Frontend Best Practices 2026: Senior Developer Checklist
- Server Components vs Client Components in Next.js
- Why Your React App Is Slow (And How to Fix It Without a Rewrite)
- How to Build a Design System From Scratch in React
- Design System Failing Developers: How to Fix It
- CSS Decisions for a Maintainable Site
- State Management in React: When You Need a Library
- Next.js Project Structure That Scales
- React vs Next.js for Startup Projects
- Frontend Development Services
- React Development Services
- Next.js Development Services