Nifra vs. other frameworks

Honest comparison. Nifra is a full-stack framework first - five UI libraries and five runtimes from one core, with loaders, actions, streaming, and a typed data layer - and a standalone typed backend you can use on its own. Here is where each tool fits.

Nifra's lane

Every other full-stack framework here is one UI library on a mostly-one-runtime story. Nifra bets the opposite axis: one core, many front-ends, many runtimes, with a contract-first typed backend in the same project.

Full-stack parity

Across the board, Nifra ships the modern full-stack feature set on all five UI frameworks:

• File routing (dynamic / catch-all / groups / optional) + nested layouts.
• SSR · SSG · ISR, streaming SSR with out-of-order Suspense, islands, view transitions, and a ~0 KB-client vanilla adapter.
• Loaders + actions + server functions (typed serverFn RPC, server code never shipped to the browser) + progressive-enhancement forms; defer() / <Await> streaming data; query cache, optimistic UI, concurrent fetchers, revalidation.
• Head/meta, hover/focus prefetch, scroll restoration.
• First-party auth, i18n, image, uploads - plus content collections + MDX, font optimization, and draft / preview mode.

The data model (loaders, actions, defer, progressive enhancement, fetchers, revalidation) is closest to Remix / React Router - delivered across five UI libraries instead of one.

Server code on every page - RSC is the one protocol Nifra trades away

Nifra covers the full server side: typed loaders and actions, streaming SSR with out-of-order Suspense, islands, and typed server functions - serverFn RPC whose body (DB handles, secrets, imports) is never shipped to the browser, callable as a normal typed function from any component, on all five UI libraries. Data on the server, mutations on the server, minimal client JS: all there, by a framework-agnostic mechanism instead of a React-only one.

What Nifra deliberately does not adopt is React Server Components as a component protocol - "use server" / "use client" directives and the server-only component tree. RSC is React-specific; a core that also serves Vue, Solid, Svelte, and Preact can't be built on it. (Nuxt, SvelteKit, and Remix don't ship RSC either - this is Nifra vs. Next App Router specifically.) So the call is simple: if your app is architected around RSC itself, Next.js App Router is the right tool. For everything RSC is usually reached for - server-side data, secrets off the client, less JS - loaders, defer(), islands, and server functions cover it here.

Also a standalone backend (vs. Hono & Elysia)

Nifra's core is a Bun-native, Web-standard server, so it stands on its own as an API - and graduates to full-stack later without a rewrite.

• Throughput - the realistic case. Router micro-benchmarks flatter Hono (a single compiled regex), but a router is ~1% of a real request - the time goes to middleware, validation, context, and serialization. In the current matrix (median of 5 full runs) Nifra tops the framework field on Bun - level with Elysia on GET /users/:id at 101% of the raw-runtime ceiling, 105% of Elysia on the validated POST - and leads every framework on Deno on both workloads. On Node it leads the framework field too - ahead of Fastify by ~12% on the validated POST (96% of the raw-Node ceiling) and level-to-ahead on GET, with Elysia, Hono, and Express behind. In the realistic shape (security headers + CORS + bearer auth + cookies + validated query/body + a ~2.4 KB JSON response, measured with oha) Nifra runs at 103% of Elysia on GET and 108% on POST. Treat benchmark rows as same-run evidence, not a permanent law of nature.
• End-to-end types. client<typeof app>() derives request inputs and res.data from the route contracts - the compiler catches frontend/backend drift. Hono's hc and Elysia's Eden are typed too, but backend-only - no full-stack page/loader story.
• Validation + OpenAPI. Any Standard Schema plus t (TypeBox - free JSON Schema), emitting a real 3.1 doc with field-level request/response schemas (+ Scalar UI).
• Batteries. @nifrajs/better-auth + session guards, @nifrajs/otel (W3C traceparent, OTel semantic conventions), and create-nifra scaffolding (framework × deploy × CI × DB × auth, with an AGENTS.md).

Run it yourself: bun run bench:realworld and bun run bench:http:compare.

The AI-agent toolchain - Nifra-only

No competitor - full-stack or backend - ships this. Every Nifra app is built to be edited by AI agents accurately:

• nifra mcp - an MCP server exposing nifra_context (the project's typed surface), nifra_example (snippets typechecked against the installed version - no hallucinated APIs), nifra_scaffold (URL → correct routes/ file), nifra_run (verify via HTTP), and nifra_check (a drift gate that returns the fix). One MCP, two transports: the docs tools are also hosted at mcp.nifra.dev (no checkout needed), while the project tools run only on your machine - your code never leaves it.
• llms.txt + llms-full.txt served at the site root, an AGENTS.md in every scaffold, and a docs corpus that can't drift from the code.
• nifra assure + nifra levels - a route-assurance gate: a policy file classifies every reflected route and CI fails naming exactly which evidence is missing (authentication on writes, validation, declared effects). Spectral lints the OpenAPI document and Semgrep pattern-matches source text; neither sees the real route graph. This is what makes agent-written routes safe to merge - an agent (or a human) cannot ship an unauthenticated write past it.

Where Nifra fits

Reach for Nifra when you want:

• One codebase, every front-end + runtime - ship the same app on React, Vue, Solid, Svelte, or Preact, running on Bun, Node, Deno, and the edge, with no rewrite to switch either.
• A type-locked stack - the typed client derives requests and res.data from your route contracts, so the compiler catches any frontend/backend drift.
• The full modern toolkit on your UI of choice - loaders, actions, streaming SSR with out-of-order Suspense, SSG/ISR, islands, query cache, progressive-enhancement forms.
• A framework AI agents edit accurately - the nifra mcp toolchain + verified, version-checked examples, which no other framework ships.
• To start lean and grow - begin as a typed API, graduate to full-stack on the same core, no rewrite.

The one deliberate trade: Nifra is streaming SSR + islands + typed server functions, not the RSC component protocol - framework-agnostic by design. Apps architected around RSC itself belong on Next App Router; everyone else gives up nothing server-side here.