React Styling and UI Libraries: Tailwind, shadcn, and Component Kits

Tailwind CSS handles styling for most new React projects. shadcn/ui has become the default way to add pre-built components on top of it. Neither is the only option. Together, though, they're the closest thing React has to a default styling stack in 2026.

This guide covers both, plus the alternatives worth knowing: MUI, Chakra, and where Tailwind fits (or doesn't) outside React. Rendering CMS content into any of these? Draftbase's MDX renderer passes a components prop straight through. Styled components slot into rich text the same way they slot into a page you built by hand.

Tailwind CSS with React: The Setup

Tailwind styles components with utility classes directly in your markup, instead of a separate stylesheet. create-next-app --tailwind sets up a working project in one command; a manual React setup needs tailwindcss, postcss, and one config file.

npx create-next-app@latest --tailwind

Tailwind v4 changed the setup itself. Configuration moved from a tailwind.config.js file to a CSS-first @theme block. The build now runs on Tailwind's own native engine, not PostCS's plugin pipeline, per Tailwind's own v4 docs. Production CSS output shrank as a result. The new engine only generates the utility classes a project actually uses.

@import "tailwindcss";
@theme {
  --color-brand: oklch(0.6 0.2 250);
}

Why React and Tailwind Pair Well

React splits a UI into small, reusable components. Tailwind styles each one inline, in the same file, with no separate CSS file to keep in sync. That locality is the actual pitch. A component's markup and its styling live in one place. Delete the component, and its styles go too, with nothing orphaned in a stylesheet.

React UI Libraries: What's Actually Different

"React UI library" covers two different things now, and mixing them up leads to the wrong pick. A traditional component library, like MUI or Ant Design, ships pre-styled components through npm. Install it, import a <Button>, and it renders with the library's own design baked in.

shadcn/ui works differently. Running npx shadcn add button copies the component's source code directly into your project. There's no package to upgrade, no version to track, since the code lives in your repo like anything else you wrote.

shadcn/ui: Copy the Code, Not the Dependency

shadcn/ui builds on Radix UI's headless primitives for accessibility and behavior. Tailwind handles the styling on top. Since the code lands in your project, you can edit a button's padding directly instead of overriding it through a theme API.

import { Button } from "@/components/ui/button";

<Button variant="outline" size="sm">Save draft</Button>

That copy-paste model has a real tradeoff, not just an upside. A security fix or an accessibility improvement upstream doesn't reach your project automatically. You own the code, which also means you own patching it.

MUI, Chakra, and the Traditional Library Model

MUI ships 70-plus components as a real npm dependency. It brings a mature theming system, plus enterprise features like data grids that most copy-paste libraries skip. It fits a data-heavy internal tool or admin panel faster than assembling the same grid from primitives.

Chakra UI sits in between. More structure than Radix alone. Less commitment than MUI's full design system. It's a reasonable pick for a prototype that needs working components fast, with less setup than either extreme.

Does shadcn/ui Work with Angular or Vue?

Not the original library. shadcn/ui is React-specific, built on React's component model and Radix's React primitives. shadcn/ui ports exist for other frameworks (shadcn-vue, community Angular adaptations), but they're separate reimplementations, not the same codebase running elsewhere.

Tailwind itself has no such restriction. vue-tailwind and standard Tailwind setups work in Vue, Angular, Svelte, or plain HTML. Tailwind only touches class names, not a framework's component model. The utility-class approach is framework-agnostic by design; the copy-paste component model on top of it, so far, isn't.

Which Should You Actually Use?

Pick Tailwind for styling on nearly any new React project. It's become the default for good reason: fast iteration, no naming-convention debates, and a build that ships only the classes you use.

For components, the split runs on how much you plan to customize. Pick shadcn/ui when you want full control over every pixel and don't mind owning the code. Pick MUI when a data grid, enterprise theming, or a similar built-in feature saves more time than the copy-paste model's flexibility is worth. Pick Chakra for a fast prototype where working defaults matter more than deep customization.

What Breaks When a Team Mixes Component Models?

A common mistake: adding shadcn/ui components on top of an existing MUI theme, expecting them to look consistent automatically. They won't, since shadcn/ui components read Tailwind's CSS variables for theming, and MUI reads its own theme object. Nothing translates between the two without manual work.

The fix isn't avoiding either library. It's picking one component model as the source of truth per project, then treating the other as an occasional guest, not a peer. A one-off MUI data grid dropped into a mostly-shadcn app is fine. Just keep its styling visually distinct on purpose, rather than fighting to blend in.

Do You Need a UI Library at All?

Not every project does. A marketing site with five pages and no forms rarely needs shadcn/ui or MUI at all. Plain HTML elements, styled with Tailwind, cover most of that ground on their own.

The calculus flips once a project grows real interactive surfaces: a settings panel, a dashboard, a form with validation states. That's where a component library starts paying for its own setup cost, since accessible focus states, keyboard handling, and ARIA attributes get hard to hand-roll correctly at scale. Skipping a library on a five-page site is a fine call. Skipping one on a twenty-screen dashboard usually means reinventing Radix's primitives, badly, one component at a time.

Conclusion

Tailwind handles styling for most new React work. shadcn/ui has become the default way to add components on top of it. That convenience costs you: you own every line you copy in. MUI and Chakra still fit projects that need a traditional library's built-in complexity or fast defaults. Rendering any of them from CMS content? Draftbase's renderer passes styled components straight into MDX through a typed components prop. The styling choice above never changes how content reaches the page.