Control UI vs shadcn/ui

Both install through the shadcn CLI, keep the same core token names, and leave MIT source in your repository. The difference starts one layer up. Control UI paints through typed CSS custom properties, so a single skin re-values the whole system at once, and CI re-checks all 16 skin modes against WCAG AA on every commit. shadcn/ui leaves paint and contrast to your team, and hands you a far larger pool of community recipes in return.

Both cover classic app UI. Choose on what you want to stop maintaining by hand, not on product type.

Numbers change monthly; architecture does not. The rows above describe structure, so they age slower than star counts or download charts would.

The overlap is deliberate. Control UI follows shadcn conventions because they proved the right ownership model for UI source:

• Source lands in your repository — no versioned component package to fight at upgrade time.
• Core color tokens keep shadcn names like --background, --primary, and --ring, so an existing theme seeds a Control UI skin instead of starting from zero.
• Installation runs through the same npx shadcn@latest add flow pointed at a registry URL.

A team can run both in one app without coordination: neither writes into the other's directories. See shadcn compatibility for the exact contract.

Scope. Both ship the surfaces every product needs — dialogs, dropdowns, forms, tables, sidebars. Control UI then extends into territory shadcn/ui does not address: streaming chat turns, prompt composers with attachment rails, collapsible agent activity, context-window graphs, task progress, and citation previews. Building those from base primitives is exactly the work agent teams repeat before writing their first feature. The trade runs the other way on charts and carousels, which shadcn/ui has and Control UI does not.

Restyling depth. With shadcn/ui, a redesign means editing class lists across installed components. Control UI separates paint from structure: components render through registered CSS custom properties, and a skin pack re-values the entire token contract — radius, color ramps, typography, bevels, even WebGL surfaces — while the component source stays untouched. One app can compile several skins and switch between them.

Anatomy stability. Control UI emits stable data-control-family and data-slot attributes, which is what lets extensions like hover effects follow every control app-wide, including portalled surfaces. In shadcn/ui the rendered markup is an implementation detail that changes with updates.

Ecosystem gravity. shadcn/ui wins this one outright: more contributors, more third-party examples, more Stack Overflow answers. Control UI's registry is younger and its community smaller. If your team relies on copying community recipes, weight that honestly.

Every component library claims a consistent design system. The question is what happens when someone re-values a color six months in. Control UI answers it with a gate instead of a guideline.

One honest limit: the runner lives in this repository, not in your install, so a skin you write yourself is not audited automatically today. What you inherit is the shipped skins already clearing the bar and the published anatomy list to point your own checks at. Lock-in covers where that governance sits.

Not by product type. A dashboard built on Control UI gets the same primitives plus the skin system and the contrast gate. Choose on these instead:

Running both is the common case, not a compromise. Many teams keep their existing components/ui/*, install Control UI beside it, and adopt the agent surfaces first. Getting started covers both paths.