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 + 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.

The line Nifra draws: no React Server Components

Nifra is classic SSR + hydration with streaming and islands — not RSC. No "use server" / "use client", no server-only component tree. That is the one thing Next.js App Router has that Nifra doesn't, and it's deliberate: RSC is React-specific and would break a core that also serves Vue, Solid, and Svelte. (Nuxt, SvelteKit, and Remix don't ship RSC either — this is Nifra vs. Next App Router specifically.) Typed loaders, defer(), and route-level code-splitting cover the same problems by a different mechanism.

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 bare Bun HTTP matrix, Nifra sits close to raw Bun and behind Elysia on most GET rows; in the current realistic preview (security headers + CORS + bearer auth + cookies + validated query/body + a ~3 KB JSON response, measured with oha), it edges Elysia. 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).
• 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.

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, not React Server Components — framework-agnostic by design. If your app is built specifically around RSC, that's the call you're making.