Next.js vs Nuxt

Reasonable defaults via code splitting and native packages, but React runtime and RSC payload wire format add weight. Good performance requires intentional investment.

Code splitting per route and prefetching are automatic, but Vue runtime ships on every page. Not lean by default.

Can be excellent with optimization but inconsistent across production sites. Large JS bundles continue to drag INP on data-heavy pages at the median.

Achievable and common in production but not automatic. SSR removes render-blocking and @nuxt/image helps LCP, but intentional optimization is required to hit green consistently.

React Server Components reduce client JS versus the Pages Router, but the React runtime is unavoidable. No automatic JS budget enforcement, discipline is required.

Vue runtime (~34kb min+gzip) ships on every page. Server-only components and NuxtIsland reduce bundle size but require opt-in - the default is a fully hydrated Vue page.

The cli sets up TypeScript, ESLint, Tailwind, and App Router preferences in under two minutes, one of the best scaffolding experiences in the JS ecosystem.

The cli produces a working project in under a minute with TypeScript configured by default. Nuxt DevTools are included. Slightly more opinionated than others.

First-class throughout. Page, layout, route, and Server Action types are auto-inferred. Next.js 15 added typed route params with practically no boilerplate.

Best-in-class for the Vue ecosystem. Auto-generated types for routes, typed responses, and auto-imported composables with full inference via Volar.

Turbopack stable in v15 dramatically improved HMR but large codebases with many RSC boundaries still stall. Vite-based competitors feel faster on complex projects.

Vite-based cold starts are fast but auto-import resolution and module system add overhead on larger projects. Changes to composables or config can trigger slow full reloads.

Improved error overlay in v14 and v15, but RSC-specific errors and wrong-context cookie calls can produce cryptic stack traces requiring framework internals knowledge.

A persistent weak spot. SSR hydration mismatch errors surface as generic Vue warnings. Module conflicts produce cryptic build errors. Nuxt DevTools help at runtime but build-time errors remain hard.

Strong static generation via generateStaticParams and ISR. Understanding when a route is actually static requires knowing the caching model, which changed between versions.

nuxt generate with route crawling and per-route prerender works well for content sites. Dynamic routes requiring runtime data need explicit enumeration.

Industry-standard SSR with streaming, React Suspense, partial pre-rendering, and Edge Runtime. The most capable SSR framework in the React ecosystem.

Nitro is genuinely excellent - streaming SSR, edge rendering, server middleware, and runtime-agnostic output for Node, Bun, Deno, Cloudflare Workers, and Vercel Edge.

Individual route segments can be static, dynamic, or streamed in the same project at the layout level. No other framework offers this level of per-segment rendering control.

The routeRules API in nuxt.config.ts is best-in-class. Individual routes can be prerendered, cached, SSR-disabled, or redirected all in one config file.

Every major headless CMS maintains official Next.js starters. Sanity, Contentful, Storyblok, and Prismic all treat Next.js as their primary integration target.

Strong ecosystem via Strapi, Storyblok, Sanity and Contentful modules, and the first-party Nuxt Content module with MDC syntax and built-in search.

Draft Mode works well with a preview API route and RSC data fetching. Clean per-CMS integration but still requires some custom wiring - not zero config.

Nuxt Content includes live reload for local dev. Headless CMS preview modes are documented but require manual setup. Storyblok has the best Nuxt-specific preview integration.

App Router supports nested layouts, route groups, parallel routes, intercepting routes, and loading or error conventions at every level. The most comprehensive file-system router available.

File-based routing via pages/, nested layouts, dynamic and catch-all segments, and NuxtLink prefetching are all solid. definePageMeta enables per-page middleware and layout rules.

RSC fetch with cache tags and revalidateTag is architecturally elegant, but the caching model changed defaults between v13, v14, and v15 - a major recurring pain point.

useFetch, useAsyncData, and $fetch handle SSR/CSR data with deduplication and payload serialization. The mental model takes time to internalize but the implementations are solid.

Route Handlers and Server Actions cover external APIs and form mutations cleanly once you understand which to use when. The separation is logical but takes time to internalize.

The server/api/ directory powered by Nitro is excellent. Typed handlers, all HTTP methods via filename convention, and edge function deployment are all first-class.

App Router colocation of page, layout, loading, and error scales well. Server and client component boundaries require discipline to keep architecture clean on large teams.

Auto-imports, composables, and Nuxt Layers architecture scale well with teams. Auto-import magic can make it harder to trace where functions come from on large projects.

Pages Router to App Router was a full paradigm shift. Cache behavior changed between minor versions. Many teams stay multiple majors behind by necessity.

Nuxt 2 to Nuxt 3 was a near-complete rewrite requiring different store, module API, and rendering engine. Within Nuxt 3 minor releases upgrades are smooth.

React developers can read page components, but RSC, async layouts, and cache segment config require dedicated onboarding. Less accessible than standard React for handoff.

Vue templates are readable but Nuxt auto-imports, the `#imports` virtual module, and server/ conventions require framework knowledge to navigate confidently.

Works well on Railway, Render, Fly.io, and self-hosted Node. Some advanced features like ISR and Edge Middleware require Vercel or a host implementing the Build Output API spec.

Nitro presets cover Node, Bun, Deno, Cloudflare Workers/Pages, Vercel Edge, Netlify, AWS Lambda, Azure Functions, Render, and Railway. The most complete adapter system of any meta-framework.

Turbopack stable for dev in v15 dramatically improved local iteration. Production builds still use Webpack and can reach 5-10 minutes on large codebases.

Vite-based production builds are fast. Type generation and Nitro bundling add overhead compared to plain Vite. A medium project typically builds in 30-90 seconds.

Vercel is generous on small projects but serverless invocations, edge compute, and bandwidth bill separately at scale. Self-hosting on a VPS significantly reduces cost.

Cloudflare Workers support via Nitro enables near-zero cost at scale for edge-rendered pages. Vue runtime size can approach the 1MB Workers script limit on feature-heavy apps.

Solid choice especially with a headless CMS. More JS runtime overhead can affect CWV on pure content pages, but excellent for sites with interactive elements.

Capable with nuxt generate and @nuxt/image but Vue runtime overhead and required optimization work puts it behind Astro for content-first sites. Well-suited when complex interactivity is needed.

Best-in-class for complex React applications. Auth, streaming, caching, Server Actions, and edge deployment all compose well for SaaS and dashboard use cases.

Strong choice for complex interactive Vue applications. Full-stack via server/api/, Vue 3 composition API, Pinia, and hybrid rendering make it excellent for SaaS and dashboard products.

RSC plus Client Components is architecturally correct for selective hydration. Context providers and animation libraries often force large client subtrees - requires discipline.

Vue's Proxy-based reactivity system is excellent for complex UIs. The composable provides SSR-safe shared state. Minor footguns around accidental reactivity loss for developers new to Vue.