Two different bets
Tamagui is one of the most ambitious projects in the React ecosystem: a universal styling framework with an optional UI kit, built to target React DOM and React Native from a single component API. Its signature feature is an optimizing compiler that analyzes your styled components at build time and extracts atomic CSS on the web while emitting StyleSheet objects on native, with hoisting and tree-flattening to cut runtime cost. On top of that sits a powerful typed token system with nestable sub-themes.
That compiler is the source of Tamagui's performance reputation and its complexity. To get the gains, your styling has to flow through Tamagui's APIs and the build plugin has to be wired into your bundler. When it's set up, you get genuine web-plus-native parity from one codebase with carefully optimized output; the cost is a more involved build and a styling model that's inseparable from the toolchain.
Vireya also wants to reach mobile, but it takes a fundamentally different path — and this is the crux of the comparison. Tamagui rebuilds your UI in real React Native components, compiled per platform, so you get genuine native views with one component API across web and native; maximum nativeness is the whole point. Vireya does not do that. It keeps a single web codebase and ships it to mobile as a hybrid native+WebView app: the web UI renders inside a native shell, and a typed RPC bridge (`@vireya/rpc`) exposes native functions to it. You don't rewrite your UI in React Native — you trade some nativeness for web velocity and fewer app-store releases for dynamic screens. It's the Mobile Bridge pattern Shopify documented and that commerce apps like Mercado Livre and Magazine Luiza use.
Beneath that, styling and scope differ too. Vireya uses static CSS Modules whose values are `--v-*` tokens, with no compiler step and no runtime CSS-in-JS, themed through `createTheme()` — a tier-based palette with light/dark and runtime switching that drives every component, block and chart. Tamagui's Bento blocks are a commercial product and it ships no first-party charts, whereas Vireya bundles pre-composed blocks and a charts library for free. Tamagui is far more mature for native today and the performance-focused choice; Vireya (v0.1.0) is the younger bet, and its hybrid bridge is still maturing (Expo first). The honest framing is two different paths to native — true React Native vs hybrid WebView — plus compiler-driven styling vs static CSS Modules and what comes in the box.
Under the hood
Reaching native: true React Native vs hybrid WebView
Tamagui's bet is true React Native. Your components compile to real native views — `View`, `Text`, native gestures — from one component API shared with the web, so a screen is genuinely native on a phone. That's maximum nativeness and the reason Tamagui exists; the cost is that your UI lives inside Tamagui's universal component model and compiler.
Vireya's bet is hybrid delivery. You keep one web codebase and ship it to mobile inside a native WebView shell, with a typed RPC bridge (`@vireya/rpc`) exposing native functions — payments, sensors, push — to the web screens. You don't rebuild the UI in React Native: dynamic screens render from the web and update without an app-store release, while native capabilities come through the bridge. It's the Mobile Bridge pattern Shopify documented and that Mercado Livre and Magazine Luiza use. The trade is honest — you give up some native feel for web velocity and shipping cadence — and Vireya's bridge is still maturing (Expo first), so Tamagui is the more proven native path today.
Styling output: an optimizing compiler vs ahead-of-time CSS Modules
Tamagui's compiler is the core of its design. At build time it reads your styled components, extracts atomic CSS for the web and StyleSheet objects for native, and applies hoisting and flattening so much of the styling cost disappears from runtime. The payoff is highly optimized universal output; the prerequisite is a build plugin in your bundler and styling expressed through Tamagui's APIs.
Vireya produces its styling ahead of time as static CSS Modules — no compiler, no build plugin, no runtime CSS-in-JS. Every value is a `--v-*` token, so the CSS is fixed at authoring time and the theme is swapped by changing token values, not by recompiling. You trade Tamagui's compiler-level optimizations for a plain build and a styling model that's independent of your bundler.
Theming: typed nestable sub-themes vs a token engine
Tamagui's theming is a typed token system with nestable sub-themes — you can scope a theme to a subtree and the types follow, which is expressive and tightly integrated with the compiler's output.
Vireya's theming is `createTheme()`: a tier-based palette with light/dark and runtime switching, expressed as one `--v-*` token layer shared across components, blocks and charts. It's a flatter, CSS-variable-based model — less compiler-coupled, swapped at runtime by changing token values rather than rebuilding.
Scope: bundled free charts and blocks vs commercial Bento
Tamagui ships its UI kit and primitives, but its Bento blocks are a paid commercial product and it has no first-party charts library, so dashboards and richer page sections are assembled separately or purchased.
Vireya bundles pre-composed blocks and a charts library in the free package, all sharing the components' tokens, so a marketing page and a data dashboard stay consistent without sourcing or paying for a separate block or chart library.
Side by side
| Vireya | Tamagui | |
|---|---|---|
| Distribution | Versioned npm package, per-component subpaths | Versioned npm packages + compiler plugin |
| Styling | CSS Modules + --v-* tokens, no compiler, no runtime CSS | Optimizing compiler → atomic CSS / StyleSheet |
| Theming | createTheme() token engine, runtime switching, light/dark | Typed tokens + nestable sub-themes |
| Build | Plain build, no styling plugin | Bundler plugin required for optimizations |
| Charts & blocks | Bundled, shared tokens, free | No first-party charts; Bento blocks commercial |
| Native mobile | Hybrid WebView + typed bridge (one web codebase) | True React Native (native components) |
| Accessibility | Radix + base-ui primitives (web) | Cross-platform a11y props |
| Maturity | Early (v0.1.0), actively built | Established, ambitious scope |
Where Tamagui shines
- It delivers genuine web-and-native parity from one component API, with carefully optimized output on both platforms.
- Its optimizing compiler extracts atomic CSS, hoists and flattens styles, giving it a strong runtime-performance story on universal apps.
- The typed theming system with nestable sub-themes is expressive and tightly integrated with the compiler.
- It keeps a small, primitives-first core that teams can build their own systems on top of.
What Vireya does differently
- Styling is static CSS Modules produced ahead of time — no optimizing compiler and no bundler plugin, so there's no styling step coupled to your build.
- Theming is a `--v-*` token layer swapped at runtime via `createTheme()`, rather than compiler-extracted styles tied to typed sub-themes.
- Pre-composed blocks and a charts library are bundled for free on the components' tokens, where Tamagui's Bento blocks are commercial and it ships no first-party charts.
- Accessibility on the web is built on Radix and base-ui primitives, and the whole system rides one shared token vocabulary across components, blocks and charts.
- Mobile is reached by shipping the web UI inside a native WebView with a typed bridge, not by rebuilding it in React Native — a different path that favours web velocity and over-the-air updates over Tamagui's true-native component model.
When to choose Tamagui
- You want true React Native — real native views — with one component API shared across web and native, and the maximum nativeness that brings.
- You want the compiler's runtime-performance optimizations on a universal web-and-native app.
- You want expressive typed theming with nestable sub-themes.
- You're comfortable wiring and maintaining the compiler plugin in your bundler to get those gains.
When to choose Vireya
- You'd rather ship one web codebase to mobile as a hybrid native+WebView app — keeping web velocity and over-the-air updates — than rebuild your UI in true React Native components.
- You'd rather theme through a runtime `--v-*` token layer than compiler-coupled typed sub-themes, with no optimizing compiler or build plugin in your toolchain.
- You want charts and pre-composed blocks bundled for free rather than paying for Bento or sourcing charts separately.
- You prefer ahead-of-time static CSS Modules and web accessibility on Radix/base-ui primitives.
Switching from Tamagui to Vireya
Migrating from Tamagui to Vireya is a change of both styling model and native strategy, so be clear-eyed about it. On the web, the concrete first step is pulling Tamagui's build plugin out of your bundler config and replacing styling expressed through Tamagui's APIs with Vireya components styled by static CSS Modules. Because the styling model is fundamentally different — compiler-extracted atomic CSS/StyleSheet vs ahead-of-time CSS Modules — components are swapped rather than retargeted, and any reliance on the compiler's optimizations is replaced by the static-CSS approach.
The bigger decision is mobile. Tamagui's screens are true React Native; Vireya's mobile story is hybrid, so you don't port those screens into another native component set — you wrap the web app in a native WebView shell and bridge native functions through `@vireya/rpc`. That's a strategic shift (true-native views to web-in-a-WebView), not a like-for-like swap, and Vireya's bridge is still maturing, so plan mobile as a trajectory rather than a drop-in. On theming you re-express Tamagui's typed tokens and sub-themes as one `--v-*` token layer through `createTheme()`, swapped at runtime rather than recompiled. The web payoff is a plainer build with no styling plugin, plus bundled charts and blocks where you'd previously have sourced Bento or a separate chart library; the trade is letting go of the compiler's optimizations and Tamagui's true-native rendering.
The bottom line
Tamagui and Vireya both want to reach mobile, but they take genuinely different paths there, and that's the real choice. Tamagui rebuilds your UI in true React Native components from one universal API, with an optimizing compiler buying real runtime-performance gains and expressive typed sub-themes — at the cost of a bundler plugin and a styling model fused to the toolchain, and it's far more proven for native today. Vireya keeps one web codebase and ships it to mobile as a hybrid native+WebView app with a typed bridge, produces static CSS Modules ahead of time with no compiler, themes everything from one runtime `--v-*` layer, and bundles charts and blocks for free where Bento is commercial. If you want maximum nativeness and peak compiler-driven performance, Tamagui leads; if you'd rather not rewrite your UI in React Native and want web velocity, over-the-air updates and a plain build with batteries included, Vireya's hybrid path fits — accepting it's the younger project and the 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 Tamagui directly.
Frequently asked questions
Is Vireya a Tamagui alternative?
They overlap on wanting to reach mobile, but they take different paths. Tamagui rebuilds your UI in true React Native components with an optimizing compiler for peak performance and typed sub-themes. Vireya keeps one web codebase and ships it to mobile as a hybrid native+WebView app, uses static CSS Modules with a --v-* token engine, and bundles charts and blocks for free. Vireya is an alternative if you'd rather not rewrite your UI in React Native; if maximum nativeness is the goal, Tamagui is the more proven choice.
Do Vireya and Tamagui both do React Native?
Not in the same sense. Tamagui does true React Native — your components compile to real native views from one universal API, so screens are genuinely native. Vireya does not rebuild your UI in React Native; it reaches mobile through hybrid delivery, running your one web codebase inside a native WebView shell with a typed bridge (@vireya/rpc) for native functions — the Mobile Bridge pattern Shopify documented and Mercado Livre and Magazine Luiza use. Different paths to native: Tamagui maximises nativeness, Vireya trades some of it for web velocity and over-the-air updates. Tamagui is more mature for native today; Vireya's bridge is still maturing, Expo first.
Does Vireya need a compiler like Tamagui?
No. Tamagui's optimizing compiler extracts atomic CSS on web and StyleSheet on native via a bundler plugin. Vireya ships static CSS Modules driven by --v-* tokens, produced ahead of time, so there's no styling compiler step and no plugin in your build.
Beyond the native path, what else differs?
Styling production and bundled scope. Tamagui produces styles through its compiler and keeps Bento blocks commercial with no first-party charts. Vireya produces static CSS Modules with no compiler step and bundles a charts library plus pre-composed blocks for free on the same tokens.
How does theming compare between Vireya and Tamagui?
Tamagui offers typed tokens with nestable sub-themes tightly coupled to its compiler output. Vireya themes through createTheme(): a tier-based --v-* palette with light/dark and runtime switching, swapped by changing token values rather than recompiling, and shared across components, blocks and charts.
Are Vireya's blocks and charts free, unlike Tamagui's Bento?
Yes. Vireya bundles pre-composed blocks and a charts library for free, sharing the components' tokens. Tamagui's Bento blocks are a commercial product, and Tamagui ships no first-party charts library.
Which should I choose?
Choose Tamagui if you want true React Native with maximum nativeness, compiler-driven runtime performance and expressive typed sub-themes, and you're fine maintaining the build plugin. Choose Vireya if you'd rather ship one web codebase to mobile as a hybrid native+WebView app — keeping web velocity and over-the-air updates — with no compiler, runtime token theming, and free bundled charts and blocks.