Skip to main content
VibeStacks

Loading the search index…

EntryAlternative

Next.js

A React framework with server rendering and full-stack features. The most capable option, and the one with the most concepts. Choose it when you need it.

Last reviewed
Applies to
Next.js 16.4
Website
nextjs.org

Good for

  • Content sites, marketing pages, and storefronts that depend on search indexing
  • Full-stack apps that need server endpoints and direct database access in the same project
  • Teams deploying on Vercel who want its platform features

Not for

  • Your first frontend project, or tools used after sign-in (Vite + React is simpler)
  • Anyone who does not want to learn server components, caching, and rendering modes

Next.js is the most popular full-stack React framework. One project holds both UI and server code: pages can be rendered on the server before reaching the browser, or generated as static pages at build time.

Why it is an alternative, not a top pick

More capability means more concepts: the boundary between server and client components, data caching, static versus dynamic rendering. These boundaries are where AI makes the most mistakes, such as using a browser API in a server component or turning a page that should be static into one rendered on every request. For people who code a little, debugging these issues is expensive.

So our advice is: start with Vite + React, and switch to Next.js when you hit the needs below.

When it is worth choosing

  • Search indexing and first-paint speed matter. Server rendering puts the content right in the HTML.
  • You need server logic without maintaining a separate backend. Endpoints, form handling, and database access live in the same project.
  • Lots of content and pages. File-based routing and build-time static generation save a lot of work.

Incidentally, the site you are reading is built with Next.js: it is a content site that generates many static pages per language, which is exactly the case above.

Helping the AI avoid mistakes

Spell out the server/client boundary in AGENTS.md (see the souvenir), and require the AI to run a production build after changes; many problems only show up at build time.

Souvenir

Take it home to your AI

Drop this AGENTS.md into your project, or paste it straight to your AI coding assistant.

AGENTS.md
# AGENTS.md (Next.js section)

## Commands
- Dev: `pnpm dev`
- Production build: `pnpm build` (required after changing routes, data fetching, or config)
- All checks: `pnpm check`

## Server and client
- Components are server components by default. Add `'use client'` at the top of a file only when it uses state, event handlers, or browser APIs.
- Keep `'use client'` as close to the leaves of the tree as possible; never mark a whole page.
- Do not use `window`, `document`, or `localStorage` in server components.
- Secrets stay on the server; environment variables exposed to the browser must start with `NEXT_PUBLIC_`.

## Data and rendering
- Keep pages that can be generated at build time static; explain why when a page must render per request.
- Server endpoints validate every input and return explicit error status codes.

## Structure
- Routes live under `app/`; business logic lives in `src/features/`, and page files only compose.

Related

  • EntryTop pick

    Vite + React

    The most versatile frontend starting point. Vite runs the dev server and build, React handles the UI, and AI knows this pair best.

  • Article

    The structure of a frontend project

    Start from the folders. A scaffold creates the skeleton, the framework decides how pages are organized, and tests and code standards guard every AI change.