Next.js Alternative: Other Frameworks, or No Framework at All

Next.js is the default way to start a React project, and for a lot of projects the default is correct. It gives you file-based routing, server rendering, and API endpoints in one codebase with one deploy. Many libraries and hosting guides document a Next.js setup first.

People searching for a nextjs alternative usually have one of two doubts. The App Router and Server Components added a server and client split inside every page, with caching rules to learn on top. And the smoothest hosting path runs through Vercel, the company that builds the framework, which some teams read as a dependency they did not choose.

Both doubts are reasonable, and neither means you should leave.

Where Next.js wins

Content and marketing sites. If most pages are public and need to arrive as HTML for search engines and link previews, server rendering is the feature you are paying for. A blog, a docs site, a storefront, or a landing page with thousands of indexed URLs is the case Next.js was shaped around.

Teams already on Vercel. Preview deploys per pull request, image handling, and edge delivery come configured. Replacing the framework means rebuilding that workflow.

Hiring and ecosystem. It is the React framework a new hire is most likely to have used, and the one a third-party SDK is most likely to have an example for.

One deploy. UI and server code ship together. For a small team that means one pipeline and one thing to roll back.

If your project is mostly public content, stop here and use it. The rest of this page is for the reader building an application: sessions, a database, billing, screens nobody sees without logging in.

The framework alternatives

Next js alternatives split into two groups: other full-stack React frameworks, and frameworks that leave React behind.

Comparisons like "tanstack start vs nextjs" or "next js vs sveltekit" ask the same thing: which framework should render my pages and run my server code together. The lists tend to skip a different question.

The option the lists skip: no full-stack framework

A logged-in application does not need server rendering for search engines, because a crawler is not signing in. That removes the main reason to couple the UI to a server runtime. What is left is an older and plainer shape: an API server that speaks HTTP, and a React client with a router that calls it.

In practice that is two programs. A backend (Hono, Fastify, Express, or anything else) owns the database, auth, and business rules. A single-page React app, built by Vite into static files, owns the screens. They meet at a URL.

The last row used to decide the matter, because splitting client and server meant hand-written fetch calls and response types that drifted. Several tools now close that gap (tRPC, OpenAPI codegen, Hono's inferred client types), which is why the split is worth considering again.

How Hype Stack is built, as one example of the split

The template is a monorepo with a Hono backend in apps/backend and a React 19 single-page app in apps/frontend, routed by TanStack Router. Types cross the HTTP boundary without a build step. Routes are validated with Zod, the function registerRoutes returns a typed Hono app, and apps/frontend/src/api/sdk.ts builds a HyperFetch client from that return type:

export const sdk = createSdk<typeof client, ApiRoutesSdk>(client);

Rename a field in a Zod schema and the frontend stops compiling. No OpenAPI file sits in between. The Expo app in apps/mobile uses the same SDK against the same API, which is what keeping the server a plain HTTP service buys.

The backend is a long-lived Node process, so it holds WebSockets and a Prisma connection pool open, and the cron scheduler and the Postgres-backed task queue run inside it. The frontend is a Vite build with no server of its own, and each app deploys independently from its own Dockerfile, so restarting the API does not rebuild the UI.

The core template is free and MIT licensed. For an app with accounts and payments, the starting point is the Better Studio template, which composes an auth starter, a layout, and a billing pack. Those packs are paid, and the CLI copies them into your repository as source.

What this shape does not give you

Server rendering. The frontend is a client-rendered SPA, and the docs describe no SSR mode for it. Better Studio includes a marketing landing page, but it renders in the browser like every other route. If organic search on public pages is how you plan to get customers, put those pages somewhere that renders HTML. Astro or Next.js on your root domain with the app on a subdomain is a common arrangement, and that site is yours to build and host.

Two deploys have their own failure modes. VITE_API_BASE_URL is baked into the frontend bundle at build time, so pointing a built frontend at a different API means rebuilding it. And the backend's FRONTEND_URL has to match the deployed site exactly, because CORS, auth callbacks, and email links all read it. A staging frontend talking to a production API fails in ways that do not look like a config error at first.

The template also ships no API rate limiting, so you write that for your own routes. The auth and billing packs lean on other companies' services: WorkOS or Better Auth for identity, Stripe for payments. The hosted ones carry their own accounts and their own bills. The product itself, meaning your tables, endpoints, and screens, is yours to write.

Which one fits

If the third branch describes you, the sections below show the template running and the exact packs it installs.