What Is Nuxt? Vue's Full-Stack Framework for Building Complete Apps

What Nuxt Actually Does

Vue is a library. That means it handles one thing really well: building interactive UI components. But a library on its own doesn't give you a routing system, it doesn't handle server-side rendering for SEO, and it doesn't have a built-in way to write backend API endpoints. You'd need to wire all of that together yourself.

Nuxt is the framework that handles all of that wiring for you.

Think of it this way: if Vue is like buying individual lumber, drywall, and wiring, Nuxt is like buying a prefab structure where the load-bearing parts are already in place. You still do the finishing work — the features, the design, the business logic — but the foundation is solid and consistent.

Specifically, here's what Nuxt adds on top of Vue:

• File-based routing — create a file at pages/about.vue and /about is now a live page. No router config needed.
• Server-side rendering (SSR) — pages can be rendered on the server before they reach the browser, which means faster load times and better SEO.
• Server routes — create files in server/api/ and they become API endpoints. Your frontend and backend live in the same project.
• Auto-imports — your own components and composables are automatically available everywhere. No import statements at the top of every file.
• Deployment optimization — Nuxt knows how to build your project for different hosting targets: traditional servers, edge functions, or static files.

If you've read our guide on what Next.js is, all of this should sound familiar. That's intentional — Nuxt and Next.js are solving the same problem for different ecosystems.

Nuxt vs. Next.js: Same Idea, Different Ecosystem

If you've been using React and Next.js, here's the direct translation to the Vue side:

Concept	Next.js (React)	Nuxt (Vue)
Pages folder	app/	pages/
API routes	app/api/	server/api/
Components	components/	components/
Shared logic	Hooks (useX.ts)	Composables (useX.ts)
Dynamic routes	[slug].tsx	[slug].vue
Config file	next.config.js	nuxt.config.ts
Component syntax	JSX (.tsx)	Single-file components (.vue)

The biggest practical difference isn't the framework — it's the component syntax. React components use JSX, which looks like JavaScript with HTML mixed in. Vue components use a single-file format with distinct sections:

<!-- React (Next.js) component -->
export default function ProductCard({ name, price }) {
  return (
    <div className="card">
      <h2>{name}</h2>
      <p>${price}</p>
    </div>
  )
}

<!-- Vue (Nuxt) component -->
<template>
  <div class="card">
    <h2>{{ name }}</h2>
    <p>${{ price }}</p>
  </div>
</template>

<script setup>
const props = defineProps(['name', 'price'])
</script>

The template section is just HTML. The script section is JavaScript. They live in the same .vue file but they're clearly separated. Many people — especially those coming from a background in HTML/CSS rather than JavaScript-heavy coding — find this separation easier to read. Your AI will generate either style fluently depending on what you ask for.

The rule of thumb: if you're already comfortable with React and Next.js, stick with it — there's no reason to switch. If you're starting fresh or you prefer HTML-like templates over JSX, Nuxt and Vue are a great fit.

File-Based Routing: Folders Become Pages

This is the feature that saves the most time when you're building with AI. Instead of configuring a router and registering every route manually, you just create files and folders. Nuxt figures out the rest.

Here's how it maps:

pages/
├── index.vue          → /
├── about.vue          → /about
├── contact.vue        → /contact
└── blog/
    ├── index.vue      → /blog
    └── [slug].vue     → /blog/my-first-post
                          /blog/another-post

The [slug] syntax creates a dynamic route — that single file handles every blog post URL, with the actual slug available inside the component. If you've worked with Next.js's App Router, this is the same idea.

Inside your [slug].vue file, you access the dynamic segment like this:

<template>
  <div>
    <h1>{{ post.title }}</h1>
    <p>{{ post.content }}</p>
  </div>
</template>

<script setup>
const route = useRoute()
// route.params.slug gives you "my-first-post"

const { data: post } = await useFetch(`/api/posts/${route.params.slug}`)
</script>

Notice that useRoute() and useFetch() are used without any import statements. That's Nuxt's auto-import system at work — we'll get to that in a moment.

For nested layouts — like a sidebar that stays visible across multiple pages — Nuxt has a layouts/ folder. Create layouts/default.vue and it wraps every page automatically. Create layouts/dashboard.vue and individual pages can opt into it:

<!-- pages/dashboard/settings.vue -->
<template>
  <div>Settings page content</div>
</template>

<script setup>
definePageMeta({ layout: 'dashboard' })
</script>

When you describe your app structure to an AI — "I need a marketing site with a blog and a dashboard section" — it will generate this folder structure automatically. Understanding it means you can read what the AI built and make changes confidently.

Server Routes and API Endpoints

This is where Nuxt becomes genuinely full-stack. The server/api/ folder works exactly like app/api/ in Next.js — files in that folder become HTTP endpoints your frontend can call.

Here's a simple example. A file at server/api/products.get.ts handles GET requests to /api/products:

// server/api/products.get.ts
export default defineEventHandler(async (event) => {
  // This code runs on the server — safe to use secrets,
  // query databases, call third-party APIs
  const products = await db.product.findMany({
    orderBy: { createdAt: 'desc' },
    take: 20
  })

  return products
})

And on the frontend, you call it with useFetch:

<template>
  <ul>
    <li v-for="product in products" :key="product.id">
      {{ product.name }} — ${{ product.price }}
    </li>
  </ul>
</template>

<script setup>
const { data: products } = await useFetch('/api/products')
</script>

The naming convention in the filename (.get.ts, .post.ts, .delete.ts) automatically restricts the endpoint to that HTTP method. You can also handle multiple methods by omitting the suffix and checking manually:

// server/api/products/[id].ts — handles GET, PATCH, DELETE for a single product
export default defineEventHandler(async (event) => {
  const id = getRouterParam(event, 'id')
  const method = getMethod(event)

  if (method === 'GET') {
    return db.product.findUnique({ where: { id } })
  }

  if (method === 'PATCH') {
    const body = await readBody(event)
    return db.product.update({ where: { id }, data: body })
  }

  if (method === 'DELETE') {
    await db.product.delete({ where: { id } })
    return { success: true }
  }
})

Server routes run in a Node.js environment (or on the edge, depending on your deployment). Your API keys, database credentials, and any logic you don't want exposed to the browser live here safely. The browser never sees server-side code.

This one-project, two-sides architecture is why AI tools reach for Nuxt (or Next.js) when you ask for a complete app. The alternative — a separate Express backend and a separate Vue frontend — is more configuration, more deployment complexity, and more ways for things to go out of sync.

Auto-Imports: The Feature That Confuses AI-Generated Code

If you're new to Nuxt and reading AI-generated code for the first time, you'll notice something odd: there are almost no import statements. Functions like useFetch, useRoute, useState, and definePageMeta appear in scripts with nothing imported at the top. Your own components appear in templates without being imported in the script.

This is intentional. Nuxt's auto-import system scans specific folders and makes everything in them available everywhere:

• components/ — every .vue file becomes a usable component by its filename
• composables/ — every exported function is available in any script
• utils/ — utility functions are auto-imported similarly
• Nuxt built-ins — useFetch, useRoute, useHead, etc. are always available

So if you create this file:

// composables/useCart.ts
export const useCart = () => {
  const items = useState('cart', () => [])

  const addItem = (product) => {
    items.value.push(product)
  }

  const removeItem = (id) => {
    items.value = items.value.filter(item => item.id !== id)
  }

  return { items, addItem, removeItem }
}

You can call useCart() in any component, any page, any other composable — without writing import { useCart } from '~/composables/useCart'. Nuxt handles the wiring.

This is a significant ergonomic win when building with AI. When you ask for a feature, the AI generates a composable, drops it in the right folder, and uses it in the component — all without a wall of import statements that can break when files move.

Real Example: Building a Task App with Nuxt

Let's walk through a simple but complete example — a task tracking app. This is the kind of thing AI generates well, and it shows how all the Nuxt pieces work together.

Here's the project structure the AI would create:

my-task-app/
├── nuxt.config.ts
├── pages/
│   ├── index.vue          ← task list page
│   └── tasks/
│       └── [id].vue       ← single task detail
├── components/
│   ├── TaskCard.vue
│   └── TaskForm.vue
├── composables/
│   └── useTasks.ts
└── server/
    └── api/
        ├── tasks.get.ts
        ├── tasks.post.ts
        └── tasks/
            └── [id].delete.ts

The server API side first — fetching all tasks:

// server/api/tasks.get.ts
export default defineEventHandler(async () => {
  // In a real app, this would query a database
  // For this example, we're returning static data
  return [
    { id: '1', title: 'Set up Nuxt project', done: true },
    { id: '2', title: 'Build the task list page', done: false },
    { id: '3', title: 'Add server API routes', done: false }
  ]
})

Creating a new task:

// server/api/tasks.post.ts
export default defineEventHandler(async (event) => {
  const body = await readBody(event)

  // Validate the incoming data
  if (!body.title || typeof body.title !== 'string') {
    throw createError({ statusCode: 400, message: 'Title is required' })
  }

  const newTask = {
    id: crypto.randomUUID(),
    title: body.title.trim(),
    done: false,
    createdAt: new Date().toISOString()
  }

  // In a real app: await db.task.create({ data: newTask })
  return newTask
})

The shared composable that handles state and API calls:

// composables/useTasks.ts
export const useTasks = () => {
  const tasks = useState('tasks', () => [])

  const { data, refresh } = useFetch('/api/tasks', {
    onResponse({ response }) {
      tasks.value = response._data
    }
  })

  const addTask = async (title) => {
    await $fetch('/api/tasks', {
      method: 'POST',
      body: { title }
    })
    await refresh()
  }

  const toggleDone = (id) => {
    const task = tasks.value.find(t => t.id === id)
    if (task) task.done = !task.done
  }

  return { tasks, addTask, toggleDone }
}

And the main page that uses it all:

<!-- pages/index.vue -->
<template>
  <div class="container">
    <h1>My Tasks</h1>

    <TaskForm @submit="addTask" />

    <div class="task-list">
      <TaskCard
        v-for="task in tasks"
        :key="task.id"
        :task="task"
        @toggle="toggleDone(task.id)"
      />
    </div>

    <p v-if="tasks.length === 0">No tasks yet. Add one above.</p>
  </div>
</template>

<script setup>
const { tasks, addTask, toggleDone } = useTasks()
</script>

Notice what's not in that page component: no imports, no router setup, no API configuration. The AI generated a clean, focused component that does exactly one thing — render the UI and respond to user interactions. All the complexity is in the composable and the server routes.

This separation is what makes AI-generated Nuxt apps relatively easy to maintain. Each file has a clear job. When something breaks, you usually know which file to look at.

When AI Picks Nuxt vs. Next.js

AI coding tools are trained on enormous amounts of real-world code. When you ask for a Vue project, the AI will reach for Nuxt because Nuxt is what the Vue community reaches for in production. It's not making a judgment call — it's following the pattern of what real Vue apps look like.

Here's a practical breakdown of when you'll see each:

AI generates Nuxt when you say:

• "Build me a Vue app with a backend"
• "I want to use Vue 3 with server-side rendering"
• "Create a full-stack app using Vue"
• "Build this in Vue instead of React"

AI generates Next.js when you say:

• "Build me a React app with a backend"
• "Create a web app" (React is often the default)
• "I want to use TypeScript and server components"
• "Build this using the App Router"

The choice isn't really about capability. For most apps — e-commerce sites, dashboards, content sites, SaaS tools — Nuxt and Next.js are technically equivalent. The decision comes down to two things:

1. Which syntax you prefer: Vue's <template> / <script> split vs. React's JSX-everywhere style
2. Which ecosystem your project already lives in: If you have existing Vue components or your team knows Vue, Nuxt is the obvious choice

If you're starting completely fresh and have no preference, React and Next.js have a larger community and more third-party library support as of March 2026. But Nuxt's ecosystem has matured significantly — the gap is much smaller than it used to be, and for many project types it's negligible.

The AI will map each piece accurately. The routing maps cleanly. The component logic maps cleanly. The main translation work is from JSX to single-file components and from React hooks to Vue composables — and even that is largely mechanical once you understand the pattern.

Understanding the Full Nuxt Project Structure

When AI generates a Nuxt project from scratch, here's the complete folder structure you'll typically see and what each piece does:

my-nuxt-app/
├── nuxt.config.ts        ← framework configuration
├── app.vue               ← root component (like _app.tsx in Next.js)
├── pages/                ← file-based routes
├── components/           ← auto-imported UI components
├── composables/          ← auto-imported shared logic (like hooks)
├── layouts/              ← page wrapper templates
├── middleware/           ← route guards (auth checks, redirects)
├── plugins/              ← third-party library setup
├── public/               ← static files (images, fonts)
├── assets/               ← files processed by the build (CSS, images)
└── server/
    ├── api/              ← API endpoints
    ├── routes/           ← non-API server routes
    └── middleware/       ← server-side middleware

You won't need all of these for every project. A simple marketing site might only use pages/, components/, and assets/. A full SaaS app will use most of them.

The nuxt.config.ts file is where you configure modules, set environment variables structure, and adjust build behavior. A minimal config looks like:

// nuxt.config.ts
export default defineNuxtConfig({
  devtools: { enabled: true },

  modules: [
    '@nuxtjs/tailwindcss',
    '@pinia/nuxt'
  ],

  runtimeConfig: {
    // Server-only secrets (never sent to browser)
    databaseUrl: process.env.DATABASE_URL,
    // Public config (available in browser too)
    public: {
      apiBase: process.env.API_BASE_URL
    }
  }
})

Nuxt has a rich module ecosystem — official modules for Tailwind CSS, authentication, image optimization, i18n, and more. When you ask AI to add Tailwind to a Nuxt project, it will install the module and add it here. Understanding this file helps you know where to look when something about your project's configuration seems wrong.

Getting Started: What to Tell Your AI

The fastest way to start a Nuxt project is npx nuxi@latest init my-app. But if you're working with an AI tool like Claude Code or Cursor, you can describe what you want to build and let the AI handle setup and structure.

Here are prompts that get good results:

Nuxt's documentation is thorough and well-organized. When AI-generated code uses a feature you don't recognize — like useAsyncData, callWithNuxt, or useNuxtApp — the official docs are the best place to understand it. The Nuxt team writes documentation that's genuinely accessible, not just for framework experts.

What to Learn Next

Now that you understand what Nuxt is and how it fits into the Vue ecosystem, here are the best next steps:

• What Is Next.js? — Understanding Next.js helps you see how Nuxt's ideas translate across ecosystems, and gives you context for why these full-stack frameworks exist.
• What Is React? — Nuxt and Vue borrowed many ideas from React. Understanding React helps you see the similarities and differences between the two ecosystems.
• What Is JavaScript? — Vue, Nuxt, and the entire ecosystem are built on JavaScript. A solid understanding of JS fundamentals makes AI-generated Vue code much easier to read and modify.

Frequently Asked Questions