Two different bets
Base UI is a set of unstyled, accessible React primitives assembled by a team with unusual pedigree: the people behind Radix, Floating UI and Material UI. It ships behaviour — focus management, keyboard interaction, ARIA wiring, positioning — and almost no opinions about how any of it should look. There is no CSS in the box. You compose the primitives and own every pixel of the visual layer yourself.
That deliberate emptiness is the appeal. Base UI targets WCAG 2.2 and the ARIA Authoring Practices Guide, so the hard, easy-to-get-wrong accessibility work is handled for you, while styling stays completely open: Tailwind, CSS Modules, vanilla-extract, plain stylesheets, whatever your design system already uses. For teams building a bespoke component library, that's exactly the right starting altitude — a behaviour foundation with no aesthetic to fight.
Vireya does not compete with that foundation so much as sit on top of it. Vireya's components are built on base-ui (and Radix) primitives, then dressed with static CSS Modules driven by `--v-*` design tokens, wired into a `createTheme()` engine, and shipped alongside pre-composed blocks and a charts library. Where Base UI hands you accessible behaviour and a blank canvas, Vireya hands you the finished, themed component — the same accessibility underneath, with the visual and theming layers already authored.
So the honest framing here is altitude, not rivalry. If you want raw primitives to style from scratch, Base UI is a clean, modern choice and Vireya literally depends on the same lineage. If you'd rather not author a design system by hand, Vireya is the layer above. Vireya is early (v0.1.0) and far younger than the primitives it consumes, so this comparison is about which layer you want to start from, not feature-count parity.
Under the hood
Headless primitives vs finished, themed components
Base UI exposes primitives as composable parts — a `Dialog` is `Root`, `Trigger`, `Portal`, `Popup`, and so on — each carrying behaviour and ARIA but no styling. You assemble those parts and write all the CSS yourself. Nothing renders with an opinion until you give it one.
Vireya consumes that same family of primitives internally and ships the assembled, styled result: a `Dialog` you import and use, already themed through `--v-*` tokens, already composing the accessible parts for you. You can still reach for raw primitives when you need bespoke behaviour, but the default is a working component rather than a kit of parts.
Accessibility target: WCAG 2.2 + APG as the contract
Base UI's central promise is accessibility correctness — it builds against WCAG 2.2 and the ARIA Authoring Practices Guide, which is precisely the layer most teams underestimate when they hand-roll components. Focus trapping, roving tabindex, escape handling, screen-reader semantics: that's the value, independent of any look.
Vireya inherits that contract by building on base-ui and Radix rather than reimplementing it. The accessible behaviour you'd get from Base UI directly is the behaviour underneath Vireya's components; Vireya's own work is the styling, tokens, theming engine, blocks and charts layered on top.
Scope: a primitive set vs a full system
Base UI is intentionally focused on primitives. It has no theming engine, no charts, no pre-composed blocks, and no mobile delivery story — by design, since those would be opinions it chooses not to hold.
Vireya is the opposite kind of project: a `createTheme()` engine with tier-based palettes and light/dark switching, plus a charts library and pre-composed blocks that all share one token vocabulary. It is a system, where Base UI is a foundation you build a system on.
Reaching mobile: web-only vs hybrid delivery
Base UI is a React (web) primitive set. There is no native delivery path in the box — if a primitive composed in Base UI needs to run on a phone, that's a separate React Native project with its own primitive layer, not something Base UI reaches into.
Vireya is designed around hybrid delivery on top of those same primitives. You compose and theme your UI once as a web app, then run it inside a native WebView shell with a typed RPC bridge (`@vireya/rpc`) exposing native functions — camera, payments, push — to the web layer. It's the Mobile Bridge pattern Shopify documented and that apps like Mercado Livre and Magazine Luiza ship, so you reach mobile without reauthoring components in React Native. The bridge is still maturing (Expo first), but it's the model Vireya is built around rather than a bolt-on.
Side by side
| Vireya | Base UI | |
|---|---|---|
| What you get | Styled, themed components + blocks + charts | Unstyled accessible primitives |
| Styling | CSS Modules + --v-* tokens, no runtime CSS | Bring your own (any CSS tech) |
| Theming | createTheme() engine, tier-based palette, light/dark | None (you own styling) |
| Beyond components | Blocks + charts included, same tokens | Primitives only |
| Accessibility | Built on Radix + base-ui primitives | WCAG 2.2 + APG primitives (Vireya builds on these) |
| Native mobile | Hybrid: web UI in a native WebView + typed bridge | React (web) only |
| License | Free, source-available | MIT |
| Maturity | Early (v0.1.0), actively built | Newer, actively developed |
Where Base UI shines
- Exceptional pedigree — built by veterans of Radix, Floating UI and Material UI, so the accessibility and positioning internals are handled by people who have shipped this twice before.
- Truly styling-agnostic: it imposes zero aesthetic and works with Tailwind, CSS Modules, vanilla-extract or plain CSS equally well.
- A modern, explicit accessibility target — WCAG 2.2 plus the ARIA Authoring Practices Guide — which is the hardest layer to get right by hand.
- A clean, focused, actively expanding primitive set with a composable parts API that stays out of your way when you need bespoke behaviour.
What Vireya does differently
- Vireya gives you finished, themed components instead of unstyled parts — the visual layer Base UI deliberately leaves blank is already authored for you.
- A `createTheme()` engine with `--v-*` tokens, tier-based palettes and runtime light/dark switching ships in the box; Base UI has no theming layer because it has no styling.
- A charts library and pre-composed blocks come bundled and share the components' tokens, where Base UI is primitives only.
- Vireya is built for hybrid delivery — the same web UI ships as a native mobile app through a WebView shell and a typed bridge — while Base UI stops at the web; and Vireya builds on the very primitives Base UI ships, so you lose none of the accessibility.
When to choose Base UI
- You're building a bespoke design system and want an accessible behaviour foundation with no styling opinions to override.
- You need maximum control of the visual layer and intend to author every component's look yourself.
- You only need accessible primitives, not finished components, a theming engine, charts or blocks.
- You're on the web only and don't need a path to ship the same UI as a mobile app.
When to choose Vireya
- You want finished, themed components rather than a kit of primitives to style from scratch.
- You want a token-driven `createTheme()` engine with light/dark and tier-based palettes out of the box.
- You want charts and pre-composed blocks bundled and sharing one token vocabulary with your components.
- You want a path to ship the same UI as a hybrid mobile app, and you'd rather inherit Base UI's accessibility through Vireya than author the visual layer yourself.
Switching from Base UI to Vireya
Moving from Base UI to Vireya is less a migration than a change of altitude, because Vireya is built on the same primitives. If your app currently composes Base UI parts and styles them by hand, adopting Vireya means deleting your bespoke styling layer and the assembly boilerplate, then importing the already-composed, already-themed component in its place. The accessible behaviour you relied on carries over unchanged, since it's the same lineage underneath.
The practical work is mapping your existing visual decisions onto `--v-*` tokens once, after which components inherit them automatically. Teams can adopt incrementally — keep hand-styled Base UI primitives where you need fully bespoke behaviour, and reach for Vireya's finished components everywhere a standard, themed control will do.
The bottom line
Base UI and Vireya are not really competitors — they're neighbours on a stack. Base UI is an excellent, modern, accessibility-first primitive set, and if you're building your own design system from the ground up it's a clean foundation backed by people who have done this before. Vireya sits one layer up, consuming those same primitives and adding the styling, theming engine, blocks and charts so you don't have to author them. Choose Base UI when you want the canvas; choose Vireya when you want the finished, themed system on top — accepting that Vireya is younger than the foundation it stands on.
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 Base UI directly.
Frequently asked questions
Is Vireya an alternative to Base UI?
They sit at different layers rather than competing head to head. Base UI gives you unstyled accessible primitives; Vireya gives you finished, styled components — and it builds on base-ui (and Radix) underneath. If you want themed components without authoring the visual layer, Vireya is the alternative; if you want raw primitives to style yourself, use Base UI directly.
Does Vireya use Base UI?
Yes. Vireya builds its components on base-ui and Radix primitives for accessible behaviour, then layers on styling via static CSS Modules and --v-* tokens, a createTheme() engine, plus pre-composed blocks and a charts library.
Do I have to write all the styling myself like I do with Base UI?
No. Base UI ships no CSS by design, so you author every component's look. Vireya ships styled CSS Modules driven by --v-* tokens — you theme by changing token values through createTheme(), not by writing the visual layer from scratch.
Is Vireya as accessible as Base UI?
Vireya's accessibility comes from building on the same lineage. Base UI targets WCAG 2.2 and the ARIA Authoring Practices Guide; Vireya inherits that behaviour by composing base-ui and Radix primitives rather than reimplementing keyboard and ARIA logic itself.
Can Vireya reach mobile when Base UI is web-only?
Base UI is React (web) only. Vireya is built for hybrid delivery: you compose and theme the UI once as a web app, then run it inside a native WebView shell with a typed bridge (`@vireya/rpc`) for native functions — the Mobile Bridge pattern Shopify documented and apps like Mercado Livre and Magazine Luiza use. So you reach mobile without rebuilding in React Native. The bridge is maturing, Expo first.
Which should I choose?
Choose Base UI if you're building a bespoke design system and want an accessible, unstyled foundation with full control of styling. Choose Vireya if you want finished, themed components, a token engine, and bundled blocks and charts — built on the very primitives Base UI provides — with a path to ship the same UI as a hybrid mobile app.