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 | 24× 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 (Vercel-optimized), partial edge support |
| React Server Components | No - deliberate (see below) | Yes, the App Router is built on them |
| AI-agent tooling | Docs/types as a live MCP server; structured verification commands | llms.txt style docs |
The 24× 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 24× 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 and Solid implementations. It is intended for the release after 4.0.0, 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.