Two different bets
shadcn/ui changed how a lot of teams think about component libraries. Instead of installing a dependency, you run a CLI and the component source — built on Radix primitives and styled with Tailwind — is written directly into your repository. From that moment the code is yours: you read it, edit it, and bend it to your design without fighting a package's abstractions.
That ownership is the whole point, and it's genuinely liberating for teams who want zero distance between themselves and their UI code. But ownership cuts both ways. Every component you copy is a component you now maintain. When shadcn/ui ships a fix or a new variant, nothing reaches your app automatically — you re-run the CLI, diff the output against your edits, and reconcile by hand, in every project that copied the code.
Vireya makes the opposite bet. It's a versioned npm package: you install it, theme it through design tokens, and receive improvements the same way you get any other dependency upgrade. On top of components it bundles a theming engine, pre-composed blocks and a charts library that all speak one token vocabulary. You trade source ownership for a maintained system that improves over time without re-pasting.
Neither bet is universally correct. The honest framing is a question about maintenance and control: do you want to own and fork every line, or do you want fixes and new components to arrive through `pnpm upgrade`? Vireya is early (v0.1.0) and far younger than shadcn/ui's ecosystem, so this comparison is about philosophy and trajectory, not feature-count parity.
Under the hood
Distribution: copy-paste source vs a versioned package
shadcn/ui is delivered by a CLI that copies TypeScript source into your project. There is no `shadcn` runtime dependency in your bundle for the components themselves — you ship the code you copied. Upgrades are a manual, per-project diff-and-merge against the code you've since edited.
Vireya is imported from `@vireya/*` packages with per-component subpaths, so you only bundle what you use and you upgrade the whole system at once. The cost is that you don't own the source to fork freely; the benefit is that maintenance is centralised and versioned.
Styling: Tailwind utilities vs tokenized CSS Modules
shadcn/ui styles components with Tailwind utility classes, so your design lives in class strings and your Tailwind config. Re-theming means editing utilities (or your Tailwind theme) across the components you copied.
Vireya ships static CSS Modules whose every value is a `--v-*` design token. There's no Tailwind dependency and no runtime CSS-in-JS — you re-theme by changing token values once, and components, blocks and charts all follow.
Scope: components vs components + blocks + charts
shadcn/ui focuses on components; blocks, charts and dashboards live in separate community or commercial projects that you assemble yourself.
Vireya bundles pre-composed blocks and a charts library alongside the components, all sharing the same tokens, so a landing page and a dashboard stay visually consistent without stitching libraries together.
Reaching mobile: web-only vs hybrid delivery
shadcn/ui is a web library. Shipping a mobile app means a separate React Native effort or wrapping the web app yourself; the components don't come with a native delivery story.
Hybrid delivery is Vireya's defining bet. You build your UI once as a web app and run it inside a native WebView shell, with a typed RPC bridge (`@vireya/rpc`) wiring critical native functions — payments, sensors, push — while dynamic screens render from the web. It's the same Mobile Bridge pattern Shopify documented and that commerce apps like Mercado Livre and Magazine Luiza use, so you reach mobile without rebuilding the UI in React Native. The bridge is maturing (Expo first via `@vireya/platform-expo`).
Side by side
| Vireya | shadcn/ui | |
|---|---|---|
| Distribution | Versioned npm package | Copy-paste source via CLI |
| Updates | Upgrade the dependency | Re-paste / re-apply by hand |
| Styling | CSS Modules + --v-* tokens, no runtime CSS | Tailwind utility classes |
| Theming | Token engine, tier-based palette, light/dark | Tailwind config + CSS variables |
| Beyond components | Blocks + charts included | Components (blocks/charts via separate projects) |
| Source ownership | Consumed as a package | You own the code in your repo |
| Primitives | Radix + base-ui | Radix |
| Native mobile | Hybrid: web UI in a native WebView + typed bridge | Web only (separate RN effort) |
| Maturity | Early (v0.1.0), actively built | Mature, very large community |
Where shadcn/ui shines
- You own the source outright — fork, rename and diverge any component with zero coupling to an upstream package.
- A huge community and an enormous ecosystem of templates, registries and blocks built on top of it.
- First-class Tailwind ergonomics for teams already fluent in utility classes.
- Maturity and battle-testing across thousands of production apps, with answers to almost any question a search away.
What Vireya does differently
- Improvements reach you through versioned upgrades instead of re-running a CLI and reconciling diffs in every repo that copied the code.
- Theming is one `--v-*` token layer that drives every component, block and chart — no Tailwind config to maintain and no utility-class edits to re-theme.
- Blocks and a charts library come in the box and share the components' tokens, rather than being separate projects you wire together.
- There's no Tailwind dependency and no runtime CSS-in-JS; the styling is static CSS Modules.
- It's built for hybrid delivery — the same web UI ships as a native mobile app through a WebView shell and a typed bridge, where shadcn/ui stops at the web.
When to choose shadcn/ui
- Owning and forking every line of component source is your top priority.
- Your team is already all-in on Tailwind and fluent in its conventions.
- You want a per-project copy you can diverge freely, with no shared dependency.
- You want the largest possible community and template ecosystem available today.
When to choose Vireya
- You want a maintained, themeable system with fixes delivered through upgrades, not manual re-pasting.
- You need consistent design tokens across many apps or brands — enterprise consistency.
- You want components, blocks and charts that share one vocabulary out of the box.
- You'd rather not depend on Tailwind or runtime CSS-in-JS, and you want a path to ship the same UI as a hybrid mobile app.
Switching from shadcn/ui to Vireya
Moving from shadcn/ui to Vireya is mostly a swap of import sources and a re-theme. Because shadcn/ui components are built on Radix and Vireya also builds on Radix (plus base-ui), the accessibility behaviour and component mental model carry over — dialogs, dropdowns, popovers and the like work the way you expect.
The real change is styling philosophy: instead of Tailwind utility classes scattered across copied source, you map your palette and spacing to `--v-*` tokens once and let components inherit them. Teams often migrate screen by screen, since both can coexist during a transition, and delete copied component folders as Vireya equivalents land.
The bottom line
shadcn/ui and Vireya solve the same surface problem — ship a polished React UI fast — with opposite strategies. If you value owning every line and you live in Tailwind, shadcn/ui's copy-paste model is hard to beat, and its ecosystem is years ahead. If you'd rather receive fixes through upgrades, theme everything from one token layer, get blocks and charts in the box, and ship the same UI to mobile as a hybrid native+WebView app, Vireya is the more maintainable foundation — provided you're comfortable adopting a younger project.
Still deciding? Read why teams choose Vireya, see how theming works, or browse the live blocks and charts showcases. You can also see other comparisons, browse UI library alternatives and the best library by use case, or read about shadcn/ui directly.
Frequently asked questions
Is Vireya a shadcn/ui alternative?
Yes, for teams who want a maintained, versioned package instead of copy-pasting component source. Vireya ships tokenized components, blocks and charts you upgrade like any dependency, whereas shadcn/ui gives you source code you own and edit directly.
What is the main difference between Vireya and shadcn/ui?
shadcn/ui is a copy-paste collection: you run a CLI, the component source lands in your repo, and you own and maintain it. Vireya is a versioned package with a token-driven theming engine, charts and pre-composed blocks, so improvements arrive through upgrades rather than re-pasting.
Does Vireya use Tailwind like shadcn/ui?
No. shadcn/ui styles components with Tailwind utility classes. Vireya ships static CSS Modules driven by --v-* design tokens, with no runtime CSS-in-JS and no Tailwind dependency. You theme by changing tokens, not utility classes.
Is it hard to migrate from shadcn/ui to Vireya?
It's mostly swapping import sources and re-theming. Both build on Radix primitives, so the accessibility behaviour and component model carry over; the main change is moving from Tailwind utility classes to --v-* tokens. The two can coexist, so teams typically migrate screen by screen.
Does shadcn/ui or Vireya have more components and ecosystem?
shadcn/ui is far more mature, with a vast community and template ecosystem. Vireya is early (v0.1.0) and growing. If breadth and ecosystem today are decisive, shadcn/ui wins; if a maintained, tokenized system with bundled charts and blocks matters more, Vireya fits.
Can shadcn/ui or Vireya ship a mobile app?
shadcn/ui is web-only — mobile means a separate React Native build or your own wrapper. Vireya is built for hybrid delivery: the same web UI runs inside a native WebView shell with a typed bridge for native functions (the Mobile Bridge pattern Shopify documented and apps like Mercado Livre and Magazine Luiza use), so you reach mobile without rebuilding the UI. The bridge is maturing, Expo first.
Which should I choose?
Choose shadcn/ui if owning and forking every line of source matters most, or you want the biggest ecosystem today. Choose Vireya if you want a themeable, maintained system with components, blocks and charts under one roof, fixes through versioned upgrades, and a path to ship the same UI as a hybrid mobile app.