NifraNifra 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 | 25x 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 25x 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 25x the requests per second of 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
Nifra does not implement React Server Components, and that is a deliberate line: RSC is a React-only architecture, and a framework core that five UI frameworks share cannot be built on it. If your application is architected around RSC itself - streaming component payloads, server-only component trees as the organizing idea - Next.js App Router is the right tool, and Nifra will not pretend otherwise. Next.js also brings the largest React ecosystem, years of production hardening at every scale, and first-party Vercel integration.
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
bunx 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.