Two different bets
Chakra UI built its reputation on developer experience. Its signature is the style-props API: you compose UI by passing visual properties straight to components — `<Box p={4} bg="gray.100" rounded="md">` — so styling lives inline with markup and feels immediate. Paired with a thoughtful accessibility foundation, that ergonomics-first design made Chakra a favourite for teams who want to move fast without dropping into separate stylesheets.
The v3 rewrite modernized the engine considerably. Component behaviour now rests on Ark UI and the Zag.js state machines underneath it — a rigorous, well-tested approach to accessible interaction patterns — while the styling layer moved toward a Panda-inspired, recipe-based model with a stronger zero-runtime direction and better React Server Component fit than earlier versions. Chakra remains mature and broad, with a large community and a paid Pro tier of pre-built blocks.
Vireya keeps styling out of JSX entirely. Rather than passing visual props to components, you write static CSS Modules whose values are `--v-*` tokens, and you theme the whole system with `createTheme()`. The styling is resolved ahead of time, not authored in markup, and the same token layer drives a bundled charts library and pre-composed blocks. Vireya is also built for hybrid delivery — the same web UI can run as a native app inside a WebView shell — where Chakra stops at the web.
The trade is authoring model and maturity. Chakra's style props are a genuine productivity boost some developers love and others find clutters markup; its accessibility is excellent and its community is years deep. Vireya is early (v0.1.0) and narrower today. The honest question is whether you want styling co-located in components or in a separate tokenized CSS layer — and whether bundled charts/blocks and React Native reach justify a younger system.
Under the hood
Styling: style props and recipes vs tokenized CSS Modules
Chakra v3 styles through a style-props API backed by a recipe engine: visual properties on components map to design tokens defined in a `createSystem` config, and recipes describe variants. The v3 direction is more static than the old Emotion-based runtime, but the authoring surface is still props in JSX — your component markup carries the styling intent.
Vireya separates the two completely. Styling lives in `.module.css` files where every value is a `--v-*` token; the component renders semantic markup and the CSS Module does the visual work. There are no style props to pass and nothing styling-related compiled at runtime — re-theming is a token change, not an edit to props across your components.
Accessibility: Ark UI / Zag.js vs Radix + base-ui
Chakra v3's interactive behaviour is built on Ark UI, which is itself powered by the Zag.js state machines — a framework-agnostic, formally-modeled approach to component state and keyboard/ARIA semantics. It's a strong, well-tested foundation.
Vireya builds its accessible behaviour on Radix and base-ui primitives instead. Both projects take accessibility seriously and arrive at similar guarantees; the difference is lineage, not whether keyboard support and ARIA are handled.
Scope: components + paid blocks vs components + blocks + charts
Chakra focuses on components and leaves charting to separate libraries; its ready-made blocks are offered through a commercial Pro tier. Assembling a full dashboard means combining Chakra's components with an external chart library and your own composition.
Vireya bundles a charts library and pre-composed blocks alongside the components, all included for free with no feature paywall and all sharing the same `--v-*` tokens, so the visual system stays consistent from landing page to dashboard without stitching libraries or paying to unlock the blocks.
Reaching mobile: web-only vs hybrid delivery
Chakra UI runs in the browser only. There's no native target — putting your Chakra app on a phone means a separate React Native project with a different toolkit, or hand-rolling a WebView wrapper around the web build.
Vireya treats mobile as a hybrid problem from the start. You keep one web codebase and host it inside a native WebView shell, with a typed RPC bridge (`@vireya/rpc`) handing native capabilities — payments, sensors, push — to the web layer while your screens render unchanged. That's the Mobile Bridge pattern Shopify wrote up, and the model commerce apps like Mercado Livre and Magazine Luiza run in production, so you don't rebuild the interface in React Native to ship an app. The bridge is still maturing, Expo first through `@vireya/platform-expo`.
Side by side
| Vireya | Chakra UI | |
|---|---|---|
| Distribution | Versioned npm package | Versioned npm package (@chakra-ui/react) |
| Styling | CSS Modules + --v-* tokens, no style props | CSS-in-JS style props (v3 recipe engine) |
| Theming | Token engine, tier-based palette, light/dark | createSystem tokens + recipes, CSS variables |
| Authoring | Semantic markup, styling in CSS Modules | Visual props inline on components |
| Charts & blocks | Bundled free, same tokens | Charts external; Pro blocks (paid) |
| Native mobile | Hybrid: web UI in a native WebView + typed bridge | Web only |
| Accessibility | Radix + base-ui primitives | Ark UI / Zag.js state machines |
| RSC / Next.js | Server-friendly, per-component subpaths | Client provider boundary |
| Maturity | Early (v0.1.0), actively built | Mature, large community |
Where Chakra UI shines
- An ergonomic style-props API that lets you compose and style UI inline, which many teams find genuinely fast and pleasant to author.
- Strong, rigorously-modeled accessibility via Ark UI and the Zag.js state machines underneath it.
- A clean, coherent design-token and theming system through `createSystem`, with a recipe-based variant model.
- v3's zero-runtime direction improves performance and React Server Component compatibility over earlier versions.
What Vireya does differently
- Styling lives in tokenized CSS Modules, not in style props on components, so your markup stays free of visual concerns and theming is a token change rather than a prop edit.
- A charts library and pre-composed blocks ship in the box for free with no feature paywall, where Chakra leaves charting to external libraries and gates ready-made blocks behind a paid Pro tier.
- Accessibility is built on Radix and base-ui primitives rather than Ark UI / Zag.js — a different lineage to the same goal.
- Vireya is built for hybrid delivery — the same web UI ships as a native mobile app via a WebView shell and a typed bridge — where Chakra is web-only and mobile means a separate React Native project.
When to choose Chakra UI
- You love the style-props authoring experience and want styling co-located with markup.
- You want Ark UI's accessible behaviour paired with Chakra's ergonomics.
- You're building for the web only and don't need a mobile delivery story.
- You value Chakra's maturity, broad component set, and large community today.
When to choose Vireya
- You prefer styling in separate tokenized CSS Modules over style props in JSX.
- You want a charts library and blocks bundled for free with no feature paywall under one token vocabulary.
- You want a path to ship the same UI as a hybrid mobile app rather than maintaining a separate React Native project.
- You want a single `--v-*` token engine with light/dark and runtime switching out of the box.
Switching from Chakra UI to Vireya
Moving from Chakra UI to Vireya means changing how you author styling more than rebuilding your app's logic. The component model — dialogs, menus, popovers, form controls — carries across, and both libraries care deeply about accessibility, so interaction behaviour translates cleanly. The visible work is relocating styling: Chakra's inline style props and recipe tokens become Vireya's `--v-*` tokens applied through CSS Modules, which is mechanical but touches every styled component.
A practical plan is to map your Chakra `createSystem` tokens onto Vireya's `--v-*` token layer first, then migrate screen by screen while both libraries coexist. If you rely on Chakra Pro blocks, you can replace them with Vireya's bundled blocks — included for free, no feature paywall — as you go. The main thing to budget for is the shift in mindset from "style in props" to "style in tokens," which is straightforward once the token mapping exists.
The bottom line
Chakra UI and Vireya both take accessibility seriously and both have moved away from heavy runtime styling, so the real divide is authoring model and scope. If you love writing styling as props inline and want Chakra's maturity and Ark UI behaviour today, Chakra is the more proven pick. If you'd rather keep markup clean and styling in a tokenized CSS layer, get charts and blocks in the box for free with no feature paywall, and reach mobile by running the same web UI as a hybrid native+WebView app, Vireya is the better fit — accepting that it's a young (v0.1.0) project against Chakra's established ecosystem.
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 Chakra UI directly.
Frequently asked questions
Is Vireya a Chakra UI alternative?
Yes. Vireya provides tokenized components, blocks and charts as a versioned package, themed through a --v-* engine and styled with static CSS Modules instead of style props. It suits teams who want styling out of JSX and a charts library and blocks included for free, with no feature paywall.
Does Vireya use style props like Chakra UI?
No. Chakra styles components with an inline style-props API. Vireya keeps styling in CSS Modules driven by --v-* tokens, so the markup stays semantic and you theme by changing tokens rather than passing visual props on components.
What accessibility model does Vireya use?
Vireya builds accessible behaviour and keyboard support on Radix and base-ui primitives, where Chakra v3 uses Ark UI and the Zag.js state machines. The lineage differs, but both prioritise accessibility and reach similar guarantees.
Is it hard to migrate from Chakra UI to Vireya?
It's mainly a change in how you author styling, not app logic. The component model and accessibility carry over; the work is moving from Chakra's inline style props and createSystem tokens to Vireya's --v-* tokens in CSS Modules. The two can coexist, so teams map tokens first and then migrate screen by screen.
Which is more mature, Chakra UI or Vireya?
Chakra is far more mature — broader, with years of community, and a polished v3 engine. Vireya is early (v0.1.0) and still growing. If maturity and breadth decide it, choose Chakra; if a tokenized CSS-Module model, bundled charts/blocks included for free with no feature paywall, and React Native matter more, Vireya fits.
Can Chakra UI or Vireya ship a mobile app?
Chakra is web-only, so an app means a separate React Native project or your own WebView wrapper. Vireya is built around hybrid delivery: the same web UI runs 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.