Stacks vs Next.js

Next.js decides how your pages render. Stacks decides the rest too.

Next.js is a rendering framework with route handlers attached. Everything behind the request, the database layer, the auth, the queue, the mail, the admin, is a decision you make and maintain. Stacks makes those decisions and ships them typed against each other.

What Next.js is.

In its own terms, not ours.

Next.js is the default way to build a React application in 2026. App Router, server components, streaming, and the image and font pipelines are excellent, the ecosystem is the largest in the space, and Vercel makes deploying a React app close to effortless. It is a front end framework that grew server capabilities, and it is honest about stopping where your data layer starts.

Where each one wins.

Same amount of room on both sides, on purpose.

Pick Next.js for

  • The React ecosystem

    Every component library, every hiring pool, every Stack Overflow answer. If your interface is React and your team is React, that gravity is real and it is worth something.

  • Server components and streaming

    The RSC model is genuinely ahead on partial rendering and client bundle size, and Stacks does not have an equivalent.

  • Vercel

    Preview deploys per pull request, edge rendering, and analytics with no infrastructure work at all. Stacks deploys to your own AWS account, which is more control and more responsibility.

  • Asset pipelines

    next/image and next/font solve real problems well, and a Stacks project handles images and fonts more manually.

Pick Stacks for

  • The backend is not an exercise

    Models, migrations, auth, roles, queues, mail, storage, search, realtime, and an admin dashboard are in the install, not in a list of packages to evaluate.

  • One type graph

    A model attribute, the action that writes it, the route that exposes it, and the view that renders it are typed against each other, so a rename is a compile error rather than a runtime surprise.

  • Infrastructure in the repository

    config/cloud.ts describes DNS, certificates, CDN, and mail records, and buddy deploy applies them. Nothing about production is configured in a console.

  • No build config to own

    STX compiles single-file components on the server without a bundler configuration surface, and buddy dev runs every surface at once.

Side by side.

The dimensions teams actually decide on.

Dimension Stacks Next.js
Rendering model Server-rendered STX components with signals for interactivity React server and client components, streaming, partial prerendering
Data layer First-party ORM, models drive migrations Choose Prisma, Drizzle, Kysely, or raw SQL
Auth Sessions, tokens, passkeys, 2FA, RBAC, gates included Auth.js, Clerk, or a service
Background work Queues, jobs, batches, schedules, workers included Inngest, Trigger.dev, QStash, or your own worker
Admin surface Dashboard generated from your models Build it, or buy Retool or similar
Runtime Bun Node.js, with edge and Bun support varying by feature
Hosting Your AWS account, server or serverless, from config Vercel first, self-hosting possible and less travelled
Language surface TypeScript everywhere, including infrastructure TypeScript, plus whatever your backend services use

If you did move.

What ports cleanly, what does not, and where to start.

Keep Next.js on the front, put Stacks behind it

A Stacks API with generated OpenAPI and a typed client is a normal thing for a Next.js app to consume. This is the lowest-risk way to try it.

Views are the real port

Route handlers and data access map over cleanly. JSX components do not: STX is its own template language, and a page is a rewrite rather than a copy.

Start with the workloads

Moving queues, mail, and cron out of a Next.js app into Stacks is usually the first thing that pays for itself.

The verdict.

Both answers are real. Most teams already know which paragraph is theirs.

Choose Next.js when

Your interface is React, your team knows it, and you want the largest ecosystem and the easiest hosting story in the industry. Next.js plus a few services is a completely reasonable stack and it is the safe choice.

Choose Stacks when

You are tired of assembling and maintaining the backend half yourself, and you would rather have one typed application with the queue, the mail, the admin, and the deploy already in it.

The frameworks that usually come up in the same conversation.