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
| Nifra | Next.js | |
|---|---|---|
| UI framework | React, Vue, Svelte, Solid, or Preact | React only |
| Server rendering | 15× throughput in our published benchmark | Baseline (see methodology below) |
| API layer | Typed routes with schema validation; client types inferred, zero codegen | Route handlers / server actions; typing is your responsibility |
| Runtimes | Bun, Node, Deno, edge workers - one app, adapter per runtime | Node and the Edge runtime; other hosts through deployment adapters |
| Server components | Opt-in: native RSC/Flight for React, server-rendered ranges for the other four (see below) | Yes, the App Router is built on them |
| Partial prerendering | Experimental, on all five UI frameworks | Yes, under Cache Components |
| Kept pages on back/forward | Per route, with keepAlive, on all five UI frameworks | A few recent routes, under Cache Components |
| Live data | Built in: loaders declare keys, a publish reloads them on every open tab | No built-in push; data refreshes on navigation or router.refresh() |
| AI-agent tooling | MCP server over the project's typed surface; structured verification commands | Dev-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.