Nifra vs Next.js

Next.js is the default full-stack React framework. Nifra is a full-stack TypeScript framework where React is one of five supported UI frameworks, the backend contract is typed end-to-end without codegen, and the same app runs on Bun, Node, Deno, or edge workers. Here is the honest comparison, including where Next.js wins.

The headline differences

NifraNext.js
UI frameworkReact, Vue, Svelte, Solid, or PreactReact only
Server rendering15× throughput in our published benchmarkBaseline (see methodology below)
API layerTyped routes with schema validation; client types inferred, zero codegenRoute handlers / server actions; typing is your responsibility
RuntimesBun, Node, Deno, edge workers - one app, adapter per runtimeNode and the Edge runtime; other hosts through deployment adapters
Server componentsOpt-in: native RSC/Flight for React, server-rendered ranges for the other four (see below)Yes, the App Router is built on them
Partial prerenderingExperimental, on all five UI frameworksYes, under Cache Components
Kept pages on back/forwardPer route, with keepAlive, on all five UI frameworksA few recent routes, under Cache Components
Live dataBuilt in: loaders declare keys, a publish reloads them on every open tabNo built-in push; data refreshes on navigation or router.refresh()
AI-agent toolingMCP server over the project's typed surface; structured verification commandsDev-server MCP endpoint (Next.js 16) and docs bundled with the package

The 15× number, honestly

In our reproducible SSR benchmark - the same dynamic page, server-rendered by each framework's production build on its default runtime - Nifra with React serves roughly 15× as many requests per second as Next.js. The harness lives in the Nifra repo, publishes its methodology, and includes rows Nifra does not win. That gap is not React being slow: it is the cost of the meta-framework layer around the render. Full tables and per-framework results are on the benchmarks page.

Where Next.js is the right choice

Next.js brings the largest React ecosystem, years of production hardening at scale, and first-party Vercel integration. Nifra's optional server-components pipeline uses native React RSC/Flight and corresponding Vue, Svelte, Solid and Preact implementations, with its own certified compiler tuple and explicit support limits.

Where Nifra wins

  • End-to-end types without codegen. The client infers request and response types directly from the server's route declarations. Rename a field on the server and the frontend fails to compile - no generated client, no drift.
  • Framework choice. The same routing, SSR, and server-function machinery serves React, Vue, Svelte, Solid, and Preact. Migrating UI frameworks stops being a rewrite of your backend.
  • Runtime portability. Deploy the identical app to Bun, Node, Deno, or edge workers by swapping an adapter import.
  • Built for AI agents. Documentation, runnable examples, and exact API types ship as a live MCP server, and verification commands (nifra check, nifra assure) return structured output an agent can act on. See why docs should be an MCP server.
  • Speed as a floor, not a feature. SSR, ISR, and raw HTTP throughput are benchmarked continuously against the field, and the numbers are reproducible from a clean clone.

Try the migration path

bun create nifra my-app --template site --framework react scaffolds the full-stack shape: file-based routes, typed loaders, server functions, and a typed client. The migration guide covers moving an existing app; the full capability-by-capability breakdown is in the comparison doc.