Two different bets
Park UI comes out of the Chakra UI organization and is best understood as a toolkit for building your own design system rather than a finished component package. Behaviour comes from Ark UI — Chakra's headless, state-machine-driven primitives — and styling comes from Panda CSS (with a Tailwind variant also offered). The pieces are designed to be assembled into a bespoke system rather than consumed wholesale.
The defining choice is distribution: Park UI ships through a CLI that copies component source directly into your repository. You own that code, so you can rename, restructure and customize it freely with no upstream package abstracting it away. That ownership is the appeal — and, as with any copy-in model, the trade-off is that maintenance and reconciliation of upstream changes become your responsibility, per project.
Vireya makes the opposite distribution bet. It's a versioned npm package: you install `@vireya/*`, theme it through a `--v-*` token engine, and receive fixes and new components the same way you'd take any dependency upgrade. The styling is static CSS Modules rather than Panda recipes or Tailwind, accessibility is built on Radix plus base-ui, and the package bundles pre-composed blocks and a charts library — neither of which Park UI ships — all on one token vocabulary.
Both projects are relatively young and serious about design systems, so this isn't a maturity gap so much as a philosophy gap. Park UI hands you Ark UI behaviour and Panda styling as source you own and tend; Vireya hands you a maintained, batteries-included package you upgrade. Vireya is early (v0.1.0), so the honest framing is about distribution model, styling engine and what arrives in the box.
Under the hood
Distribution: copy-into-repo CLI vs a versioned package
Park UI's CLI writes component source — Ark UI behaviour wired up with Panda recipes — straight into your project. There's no Park UI runtime dependency carrying those components; you ship and own the code, and upgrades mean re-running the CLI and reconciling against edits you've made, in each project that copied it.
Vireya is imported from `@vireya/*` with per-component subpaths, so you bundle only what you use and upgrade the whole system at once. You don't own the source to fork freely, but maintenance is centralised and versioned — fixes arrive through `pnpm upgrade`, not a re-paste pass.
Behaviour and styling: Ark UI + Panda vs Radix/base-ui + CSS Modules
Park UI's accessible behaviour is Ark UI: framework-agnostic state machines covering open/close, focus, selection and keyboard semantics, which is why Park UI can target multiple frameworks beyond React. Styling is Panda CSS recipes and design tokens (or a Tailwind variant), compiled to static CSS.
Vireya's behaviour is Radix plus base-ui, React-focused on the web. Styling is static CSS Modules whose every value is a `--v-*` token, with no Panda build pipeline or Tailwind. Re-theming is a token change via `createTheme()` rather than editing recipes or a Tailwind config.
Scope: a toolkit to assemble vs a bundled system
Park UI gives you primitives and patterns to compose into a design system; it doesn't ship charts or a block library, so dashboards and pre-built sections are yours to build or source elsewhere.
Vireya bundles pre-composed blocks and a charts library alongside the components, all sharing the same tokens, so a marketing page and a data dashboard stay visually consistent without wiring separate libraries together.
Reaching mobile: web frameworks vs hybrid delivery
Park UI's Ark UI core lets it target multiple web frameworks — React, Solid, Vue — but it's a web toolkit; there's no mobile delivery story bundled with it. Shipping a phone app means a separate React Native effort or wrapping the web app yourself.
Vireya is also a web library at heart, but mobile is part of its design. You build the UI once for the web and run it inside a native WebView shell, with a typed RPC bridge (`@vireya/rpc`) exposing native functions — camera, payments, push — to the web screens. It's the Mobile Bridge pattern Shopify documented and that apps like Mercado Livre and Magazine Luiza use, so you reach mobile without a second component set. It's an emerging path (Expo first) rather than a finished product, so treat it as Vireya's direction, not a turnkey deliverable.
Side by side
| Vireya | Park UI | |
|---|---|---|
| Distribution | Versioned npm package, per-component subpaths | Copy-into-repo via CLI |
| Updates | Upgrade the dependency | Re-run CLI / maintain owned source |
| Styling | CSS Modules + --v-* tokens, no build pipeline | Panda CSS (or Tailwind) recipes, compiled |
| Theming | createTheme() token engine, tier-based palette, light/dark | Panda tokens + recipes (owned) |
| Accessibility | Radix + base-ui primitives | Ark UI state machines |
| Charts & blocks | Bundled, shared tokens, free | None — assemble your own |
| Native mobile | Hybrid: web UI in a native WebView + typed bridge | Web only |
| Maturity | Early (v0.1.0), actively built | Newer, Chakra-org backed |
Where Park UI shines
- Ark UI gives Park UI a robust, framework-agnostic accessibility foundation built on explicit state machines, usable beyond React.
- The copy-into-repo model means you own every line of component source — full customization with no black-box package between you and your UI.
- It offers a real styling choice — Panda CSS recipes or a Tailwind variant — letting teams pick the engine they already know.
- Backing from the Chakra UI organization gives it design-system credibility and a clear focus on bespoke systems rather than drop-in widgets.
What Vireya does differently
- Vireya is a versioned package, so fixes and new components arrive through an upgrade instead of re-running a CLI and reconciling owned source in every repo.
- Styling is static CSS Modules driven by `--v-*` tokens — no Panda recipes to author and no Panda build step, and no Tailwind variant to configure.
- Pre-composed blocks and a charts library are bundled and share the components' tokens, where Park UI ships neither and leaves dashboards to you.
- Theming is one `createTheme()` token layer with tier-based palette, light/dark and runtime switching, rather than Panda tokens plus recipes you maintain as source.
- Mobile is a hybrid path — the same web UI ships as a native app through a WebView shell and a typed bridge — where Park UI's reach stops at web frameworks.
When to choose Park UI
- You explicitly want to own component source and build a bespoke design system from primitives.
- You prefer Ark UI's state-machine behaviour and want Panda CSS (or a Tailwind variant) as your styling engine.
- You need to target frameworks beyond React, where Ark UI's framework-agnostic core pays off.
- You want maximum control and are comfortable taking on the maintenance of copied source.
When to choose Vireya
- You want a maintained package with fixes through upgrades, not source you copy and reconcile per project.
- You'd rather theme through `--v-*` tokens than author Panda recipes or configure Tailwind.
- You want charts and pre-composed blocks included rather than assembling a dashboard kit yourself.
- You want a path to mobile that ships your web UI as a hybrid native+WebView app, not just web framework reach.
Switching from Park UI to Vireya
Moving from Park UI to Vireya is largely a distribution and styling shift. The biggest change is that you stop owning component source: instead of CLI-copied Ark UI + Panda components living in your repo, you consume `@vireya/*` as a versioned dependency. Where you'd previously edit copied files to customize, you now adjust `--v-*` tokens. Behaviourally the surfaces are comparable — open/close, focus and keyboard semantics behave as you expect — but Ark UI and Radix/base-ui aren't interchangeable APIs, so components are swapped rather than retargeted.
The styling migration replaces Panda recipes (or your Tailwind variant) with token-driven CSS Modules. You map your palette and spacing into `createTheme()` once and let components, blocks and charts inherit it, and you can delete the Panda pipeline from your build. Teams usually migrate incrementally — Vireya and copied Park UI components can coexist — retiring owned source folders as Vireya equivalents land, and they gain bundled charts and blocks without sourcing a separate dashboard kit.
The bottom line
Park UI and Vireya both take design systems seriously but answer the ownership question oppositely. Park UI hands you Ark UI behaviour and Panda styling as source you copy, own and tend — ideal if a bespoke, fully-owned system and framework reach beyond React are what you're after. Vireya keeps the source in a versioned package, themes everything from one `--v-*` token layer, bundles charts and blocks for free, and offers a hybrid path to mobile — the same web UI inside a native WebView with a typed bridge — rather than stopping at the web. If owning and customizing every line matters most, Park UI fits; if you'd rather receive fixes through upgrades, get batteries included, and have a route to mobile, Vireya is the more maintainable foundation — accepting it's the younger project and the hybrid bridge is still maturing.
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 Park UI directly.
Frequently asked questions
Is Vireya a Park UI alternative?
Yes, for teams who want a maintained, versioned package instead of copy-into-repo source. Vireya ships tokenized components, blocks and charts you upgrade like any dependency, plus a hybrid path to mobile; Park UI copies Ark UI + Panda components into your repo for you to own and customize.
Does Vireya copy source into my repo like Park UI?
No. Park UI uses a copy-into-repo CLI so you own and maintain the component source. Vireya is consumed as a versioned package with per-component subpaths — improvements arrive through upgrades rather than re-running a CLI and reconciling diffs.
Does Vireya use Panda CSS or Tailwind like Park UI?
No. Park UI styles with Panda CSS recipes (or a Tailwind variant), compiled at build time. Vireya ships static CSS Modules driven by --v-* tokens, with no Panda pipeline and no Tailwind. You re-theme via createTheme() at the token layer.
How does accessibility compare between Vireya and Park UI?
Park UI builds on Ark UI's framework-agnostic state machines, which is part of why it can target multiple frameworks. Vireya builds on Radix plus base-ui, React-focused on the web. Both aim at solid focus, keyboard and ARIA behaviour, but the primitives aren't interchangeable APIs.
Can Vireya or Park UI ship a mobile app?
Park UI is a web toolkit — its Ark UI core reaches React, Solid and Vue, but mobile means a separate React Native effort or your own wrapper. Vireya is also web-first but reaches mobile through 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 don't rebuild the UI. The bridge is maturing, Expo first.
Which should I choose?
Choose Park UI if owning component source, building a bespoke system, and reaching frameworks beyond React matter most, and you're happy maintaining copied code. Choose Vireya if you want a maintained, token-themed package with charts and blocks in the box and a hybrid path to ship the same UI as a native+WebView mobile app.