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 rendering24× 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 (Vercel-optimized), partial edge support
React Server ComponentsNo - deliberate (see below)Yes, the App Router is built on them
AI-agent toolingDocs/types as a live MCP server; structured verification commandsllms.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.