cheapstack
RSSBrowse stacks
framework / 05 — updated may 2026

Nuxtby nuxtlabs · vue.js team

Vue's Next.js. The most opinionated full-stack framework in the Vue ecosystem, with auto-imports, file-based everything, and a server engine (Nitro) that deploys to nearly every host. The right answer if your team writes Vue.

languageTypeScript-first · Vue 3
runtimeNitro · Node · Edge · Bun · Deno
renderingSSR · SSG · ISR · hybrid
bundlerVite (default in Nuxt 3+)
Skip to verdictSee pricing →
verdict.txt — frameworks/nuxt.mdhonest
$cat verdict.txt

Pick Nuxt if your team is Vue-shaped. The framework is mature, well-documented, and increasingly competitive with Next.js on raw capability — only the React ecosystem's gravity keeps it less famous than it deserves.

Updated May 2026read the full reasoning →
verdict / bull case + bear case

Why we picked it — and why we might not

Nuxtis the default React framework in 2026 not because it’s the smallest or the simplest, but because it’s the one with the least friction across the widest set of problems — provided your problem is shaped like a React product on Vercel.

The bull case is straightforward. App Router, Server Components, and Server Actions collapse what used to be three layers (page, API route, client fetcher) into one mental model. The Vercel deploy story is unmatched — push to git, get a preview URL, promote on click. The ecosystem is the largest in React: every auth provider, every database client, every UI library has a first-class Nuxt example, and the AI assistants understand Nuxt better than they understand any other framework. For a team that’s already on React, choosing Nuxt means choosing the path with the most documentation, the most third-party integrations, and the most worked examples.

The bear case is also real. The cache model is the most complex in the ecosystem; newcomers fight it before they understand it, and “wait, is this server or client?” is a permanent confusion for the first month. Bundle size meaningfully exceeds Astro and SvelteKit — fine if you’re using RSC, pure overhead if you’re not. Lock-in is medium-strength: ISR-on-demand, image optimization, and middleware all bind tighter to Vercel-style hosts than to a generic Node server. Self-hosting works, but you trade deploy ergonomics for it.

For most product teams the calculus comes out in Nuxt’s favor, but the failure modes are specific and worth naming. If your app is a SPA, Vite + React Router ships less code. If your site is content-first, Astro is a better fit. If you need a pure backend, Hono or Fastify are the right answer. The honest summary: Nuxt is the right default, not the right answer in every case.

scoreboard / at a glance

At a glance

One row per dimension. The value is what Nuxtgives you; the note is the editorial framing — the quiet caveat that the marketing page won’t mention.

Routing
file-system · pages/ · nested layoutsSame conventions as Next.js Pages Router, with Vue-shaped <NuxtPage /> outlets.
Rendering
SSR / SSG / ISR / SPA — per-routeHybrid rendering with route rules (routeRules in nuxt.config). Comparable flexibility to Next.js.
Data fetching
useFetch / useAsyncData · type-safe composablesComposables run universally (server + client), with caching built in. Cleaner than Next.js's RSC/client split.
Auto-imports
components, composables, utils — all auto-importedLess ceremony than React. Components in /components are usable anywhere without import statements.
Server (Nitro)
API routes + server middleware in /serverNitro is the server engine — also used standalone. /server/api/* gives you typed API routes for free.
Hosting fit
Vercel · Cloudflare · Netlify · Node · static · Bun · DenoNitro adapters cover more hosts than Next.js's adapter ecosystem — including AWS Lambda, Azure, Firebase.
Bundle size
comparable to Next.js · smaller than React+Next baselineVue 3's runtime is smaller than React's; the framework overhead is similar.
TypeScript support
first-class · auto-generated types for routes / APIGenerated types for routes, params, API responses. Among the cleanest TS DX in metaframework-land.
Lock-in
low · Nitro's adapters keep you portableSelf-hostable, multi-host portable. Less Vercel-specific feature reliance than Next.js.
Framework age
9 years (Nuxt 2 → 3 was a major rewrite) · Nuxt 4 in 2025Mature; Nuxt 3 (Nov 2022) was the modern rebuild. Nuxt 4 (mid-2025) refined the file structure conventions.
pricing / three scenarios

Pricing at three scales

Three receipts at three traffic shapes. Numbers are illustrative — list-tier prices from May 2026, rounded to the dollar. Nothing here is invented; actual bills will vary with usage shape.

hobby.txt — 1k MAU · weekend projectmonthly
line itemdetailcost
HostingCloudflare Pages — freefree
DatabaseTurso free tierfree
TOTAL · monthlyfree/mo
>Nitro's Cloudflare adapter is mature; deploys cleanly to Pages free tier. The Vue ecosystem's typical hobby stack matches the React one in cost.
side-project.txt — 10k MAU · steady traffic · paying customersmonthly
line itemdetailcost
HostingVercel Pro · or Cloudflare Pages free$20
DatabaseNeon Launch · or Turso Scaler $9$19
Bandwidthwithin Pro 1TBfree
TOTAL · monthly$39/mo
>Same bill as Next.js at this scale because the limiting factor is hosting + DB, not framework. Switching to Cloudflare Pages + Turso drops this to ~$9/mo if you'd rather optimize for cost.
scale.txt — 100k MAU · production · multi-regionmonthly
line itemdetailcost
HostingVercel Pro + Active CPU · or CF Pages$60
Bandwidth1TB+ over Pro · or CF unlimited$60
DatabaseNeon Scale$69
Functionsoverage / Workers paid$30
TOTAL · monthly$219/mo
>Roughly the same bill as Next.js at scale on Vercel — both frameworks hit the same Vercel pricing curve. Switching to Cloudflare Pages collapses this to ~$34/mo (matching the SvelteKit / Astro / Remix scale receipts).
features / deep dives

Feature by feature

Six rows. The body describes how the feature works in 2026; the honest tradeoff is the part the docs won’t tell you. Skim the bold lines if you’re in a hurry.

01

Auto-imports

less ceremony, more code

Components in /components are auto-imported by name — no import statements at the top of files. Same for composables in /composables and utility functions in /utils. Vue’s built-in composables (ref, computed, useFetch) are auto-imported globally.

Honest tradeoff

Less typing, less import noise. The downside: search-by-import doesn't work — you find a usage site and have no way to grep for the source file unless your editor handles auto-import resolution well.

02

useFetch / useAsyncData

the data-fetching composable

useFetch('/api/items') returns a reactive data ref, runs once on the server during SSR, and hydrates correctly. useAsyncData wraps any async function with the same SSR-aware pattern. Type-safe end-to-end when your API routes are typed.

Honest tradeoff

Cleaner than Next.js's RSC + client split — one composable handles both. The downside is the magic: useFetch's caching, deduplication, and hydration semantics take time to fully understand.

03

Nitro server

the API routes + server engine

Nitro is the server engine that powers Nuxt. Files in /server/api/ become typed API endpoints. /server/middleware/runs on every request. Nitro is also used standalone (in non-Nuxt projects) — it’s a credible standalone server.

Honest tradeoff

API routes feel native, not bolted on. The downside: Nitro is a less-known abstraction than Express or Hono, and debugging server-only issues sometimes requires reading Nitro source.

04

Route rules

per-route rendering and caching

nuxt.config.ts’s routeRules lets you set rendering mode per route or path pattern: '/blog/**': { swr: 3600 } for ISR-like behavior, '/api/**': { cors: true } for CORS, etc. Centralized config beats per-page exports.

Honest tradeoff

Centralized route rules are easier to audit than Next.js's per-file exports. The downside: changes to nuxt.config require a build restart in some cases — slower iteration than per-file exports.

05

Modules

the Nuxt extension story

Nuxt modules (e.g. @nuxt/content, @nuxt/image, @nuxtjs/tailwindcss) are first-class extensions that wire features into the framework with one config line. The module ecosystem is dense and curated.

Honest tradeoff

Modules collapse setup time for common features (CMS, image optimization, PWA, i18n). The downside: when a module abstracts something you want to customize, you fight the module rather than work directly with the underlying tool.

06

Vue 3 + script setup

the underlying component model

Vue 3’s <script setup> syntax is the default. Components are SFCs (single-file components) with template, script, and style sections. Reactivity via ref/reactive; computed values via computed. Templates use directive syntax (v-if, v-for) rather than JSX.

Honest tradeoff

Vue's template syntax is more declarative than JSX and easier for non-React-shaped engineers. The downside: smaller talent pool than React, less AI-assistant fluency, fewer libraries.

fit / use or skip

Use it for, skip it for

use / nuxt

Use Nuxt for…

  • Your team writes Vue and you want a framework that takes the same opinions React-Next.js teams take for granted.
  • Auto-imports + module ecosystem + Nitro feel like the right level of opinionated — productive defaults, escape hatches when needed.
  • You want the broadest deploy story in the metaframework world — Nitro adapters cover more hosts than Next.js or Remix.
  • Type-safe composables and auto-generated route types meet the bar your team expects from TypeScript.
  • The Vue community's design and tooling sensibilities resonate more than React's culture.
skip / nuxt

Skip Nuxt for…

  • Your team is React-shaped — the framework is fine but the talent and ecosystem gap will compound for years.
  • AI-assisted code is core to your workflow — Claude/Copilot are still meaningfully better at React than at Vue.
  • You need React-specific libraries (React Native parity, niche React UI kits, React Aria) — they don't exist for Vue.
  • RSC / streaming is a workflow priority — Vue's reactivity model doesn't map 1:1 to RSC and Nuxt doesn't try.
  • You're hiring from a React-dominant job market and team familiarity matters more than framework choice.
gotchas / observed

Gotchas worth knowing

Six pitfalls visible in public docs and community discussion. None will stop you shipping; all of them will cost you an afternoon if you don’t know about them.

  • Nuxt / auto-imports

    Auto-imports break type narrowing in some IDEs

    VS Code's TypeScript server sometimes loses track of auto-imported types after a hot reload. Restarting the TS server (Cmd+Shift+P → 'Restart TS Server') fixes it. The auto-import magic is real DX win, but the IDE integration has rough edges.

  • Nuxt / hydration

    Server-only and client-only mismatches are silent

    A component that uses process.server branches differently on server vs client without obvious signal. Hydration mismatches manifest as broken interactivity rather than clear errors. Wrap browser-only code in <ClientOnly> or use onMounted.

  • Nuxt / nitro

    Nitro adapter switches require a clean build

    Switching from `nuxt-cloudflare` to `nuxt-vercel` in your config sometimes leaves stale .output artifacts. Run `rm -rf .output .nuxt` before rebuilding for the new target. The error message is unhelpful when stale artifacts conflict.

  • Nuxt / state

    useState() doesn't share across SSR requests by default

    Nuxt's `useState()` is request-scoped — fresh state per request on the server. Two requests to the same page get independent state, which is what you want. Forgetting this and treating useState as global cache leads to subtle bugs.

  • Nuxt / modules

    Module load order matters

    Some modules need to be loaded before others (e.g., @nuxt/image needs to register before content modules that use it). The module array in nuxt.config is order-dependent. Reordering 'just to clean up' breaks things — leave the order alone unless you have reason.

  • Nuxt / build

    Default static target generates routes from <NuxtLink />

    With ssr: true and nitro.preset: 'static', Nuxt crawls every <NuxtLink> at build time to generate static routes. Pages not linked from anywhere don’t generate. Use generate.routes to declare them explicitly, or rely on dynamic routes via routeRules.

how it compares / different bets

How it compares

Three short framings. No clear-winner declarations — these are different bets, and the right pick is mostly a question of what you’re optimizing for. Linked comparison pages have the side-by-side detail.

Nuxt ━▶ Next.jsdifferent bets

The two are the most architecturally similar frameworks in this set — file-system routing, hybrid rendering, full-stack defaults. Next.js wins on ecosystem reach, AI fluency, and React Server Components. Nuxt wins on auto-imports, route rules, and Nitro's broader adapter coverage.

The pick is mostly about which underlying framework (Vue vs React) your team already knows. Cross-framework migration is rare and rarely worth the cost.

Nuxt ━▶ SvelteKitdifferent bets

SvelteKit's compiler ships less JS than Vue at the same scope, and the runtime is lighter. Nuxt has the larger ecosystem and richer module library.

Pick Nuxt for Vue-shaped teams and SvelteKit for Svelte-shaped teams. The frameworks are similar in capability; the underlying language and ecosystem are the deciding factor.

Nuxt ━▶ Astrodifferent bets

Astro ships zero JS by default and is content-first. Nuxt is app-first with full-page hydration. The frameworks barely overlap.

Pick Nuxt for Vue-shaped products. Pick Astro for content-shaped sites that may use Vue islands among others. Many Nuxt teams use Astro for the marketing site and Nuxt for the app.