Nuxt
The full-stack meta-framework built on Vue.
Nuxt adds server-side rendering, file-based routing, auto-imports, and a full-stack server layer (Nitro) on top of Vue. It's the framework this site itself is built with. Where plain Vue leaves routing, data fetching, and deployment target entirely up to you, Nuxt makes opinionated defaults for all of them while still allowing you to opt out of any one of them.
When to use it
- SEO matters — Nuxt server-renders pages by default, so crawlers see full content immediately
- You want file-based routing and auto-imported components/composables to cut boilerplate
- You want a single framework that also handles simple backend/API routes (via Nitro) without a separate backend for basic needs
- You're already committed to Vue and want the most complete framework built on it
Considerations
- Server-rendering adds infrastructure and hosting considerations a plain SPA doesn't have
- The convention-over-configuration approach (auto-imports, file-based routing) has a learning curve if you're used to explicit imports
- For a purely internal dashboard with no SEO need, the SSR machinery may be more than you need — a plain Vue + Vite SPA can be simpler
Key concepts
File-based routing
Files under pages/ automatically become routes — no manual router configuration for the common case.
Auto-imports
Components, composables, and Vue APIs (ref, computed, etc.) are available without explicit import statements.
Nitro
Nuxt's server engine — powers API routes, server middleware, and deployment to many targets (Node, serverless, edge) from one codebase.
Rendering modes
Choose per-route between SSR, static generation (SSG), and client-only rendering depending on the page's needs.
Getting started
npx nuxi@latest init my-appScaffold a new Nuxt project.
cd my-app && npm install && npm run devInstall dependencies and start the dev server.
Common mistakes
- Using browser-only APIs (window, document, localStorage) directly in setup() without guarding for SSR — this code runs on the server first, where they don't exist, and crashes on first render unless wrapped in onMounted or a client-only check.
- Relying on auto-imports without knowing what's actually being imported — can make it harder to trace where a composable or component is defined, especially for newer team members.
- Defaulting every route to SSR when a page doesn't need it — an internal dashboard with no SEO requirement usually doesn't need the added server infrastructure SSR brings.
Ecosystem
Related guides
Related tools
This guide states trade-offs, not a single "best" answer — the right choice depends on your team, constraints, and existing stack.
