Comparison

This table compares @lazarv/react-server against other popular React frameworks and routing solutions. The comparison covers full-stack features, architecture, routing, type safety, search params, scroll restoration, and developer experience.

This comparison summarizes the feature set described in the documentation. It focuses on first-class, built-in support rather than custom userland solutions. Some rows describe core architecture, others cover convenience or router ergonomics, so the table should be read as a map of tradeoffs, not a single score.

This comparison is maintained by the @lazarv/react-server team. If you find an inaccuracy, please open an issue — we want this to be fair and factual.

Legend:

• ✅ — First-class, built-in support that is documented and part of the framework’s intended model
• 🟡 — Partial support, important limitations, or support that exists only in a narrower subset of use cases
• 🔶 — Possible through userland composition, community plugins, or manual setup, but not a first-class built-in feature
• 🛑 — No meaningful built-in support

@lazarv/react-server is a full React Server Components runtime — not just a router. The routing system is deeply integrated with RSC streaming, server functions, and the Vite build pipeline. This means features like typed routes, client-only routes, and server-side validation work end-to-end without glue code.

Key architectural differences

• RSC-native: Unlike routers that bolt RSC support on top, @lazarv/react-server was built from the ground up for React Server Components. Every route can mix server and client components freely.
• Client-only routes: Pages with "use client" in the file-system router are automatically client-only — navigation skips the server entirely. No configuration needed, and component state is preserved across navigations via React's <Activity> component.
• Schema-agnostic validation: Route params and search params can be validated with any schema library (Zod, ArkType, Valibot) or lightweight parse functions — the runtime detects the validation strategy automatically.
• RSC + typed resources: @lazarv/react-server offers two complementary data-fetching approaches: React Server Components with async/await (RSC as loaders), and typed resources — schema-validated, reference-identified data descriptors with .use() (suspense), .query() (imperative), .prefetch(), and .invalidate(). Resources use "use cache" as the caching runtime — no custom cache layer, no SWR boilerplate. Route-resource bindings enable parallel prefetching on navigation.
• Route-level dependencies: TanStack Router exposes route context as a first-class typed primitive for passing dependencies (auth, DB clients, etc.) down the route tree. @lazarv/react-server models the same problem space through typed resources, request context, and native modules — there is no separate route-context bag because resources already carry schema-validated, route-scoped data with full type safety.
• No devtools yet: Route devtools are planned. The tradeoff today is that the typed route system provides compile-time safety that catches most routing errors before they reach the browser.
• Outlets vs. parallel routes: @lazarv/react-server uses named outlets (@sidebar, @content) rendered as typed props to layouts. This is functionally similar to Next.js parallel routes but with stronger typing — each outlet is a branded React element that prevents accidentally swapping outlets.
• Waku: Waku is another RSC-native framework built on Vite, but takes a deliberately minimal approach. It provides basic file-based routing with layouts and RSC support, but lacks the typed routing system, search param handling, scroll restoration, middleware, and most advanced routing features. Waku's Link component supports basic scroll and prefetchOnEnter/prefetchOnView props, but most of its router API is still marked as unstable_. Waku is a good choice for simple RSC applications that don't need advanced routing.