Why we use Nuxt for almost everything we ship.

We've been writing Nuxt since v1. We rewrote our own site in Nuxt 2 in 2018 and we'll do it again in Nuxt 3 next year. We've shipped 30+ client and own-built systems on Nuxt across that decade. Some honest thoughts after the long run.

What Nuxt actually is

It's not a UI framework. Vue is the UI framework. Nuxt is the meta-framework that wraps Vue with a server, a router, a file-based page convention, an SSR pipeline, a build system, a deployment story, and a module ecosystem that lets you snap in everything from auth to CMS to image optimisation without writing the glue yourself. Think 'Next.js for Vue' if you've used Next.

What it gets right

• 01Server-side rendering as the default, with hydration that mostly behaves.
• 02File-based routing that makes structure obvious to new joiners.
• 03Server APIs in the same project, with the same auth context, with the same TypeScript types as the client.
• 04An ecosystem of modules — Nuxt UI, Nuxt Content, Nuxt Image, Nuxt Auth, Pinia — that compose properly.
• 05Static generation via nuxt generate is genuinely first-class. Same code base, same components, output is pre-rendered HTML.
• 06Deploy targets are pluggable — Vercel, Netlify, Cloudflare Pages, AWS Lambda, a regular Node server, all from the same project.
• 07Performance defaults that are sensible — code splitting per route, lazy components, automatic critical CSS extraction.

What it doesn't

• 01Hot reload still occasionally gives up the ghost on complex projects.
• 02Some module APIs change between majors — budget for it.
• 03Complex client-only flows need careful import guards.
• 04Documentation occasionally lags behind feature releases.
• 05When the framework crashes during dev, the error trace can be obscure.

A typical Nuxt page

What a typical page in a production Nuxt project looks like for us. SSR-ready data fetching, head meta for SEO, scoped styling, all in one file.

<script setup lang="ts">
import { getProductBySlug } from '~/data/products'

const route = useRoute()
const product = computed(() => getProductBySlug(String(route.params.slug)))

if (!product.value) {
  throw createError({ statusCode: 404, statusMessage: 'Not found' })
}

useSeoMeta({
  title: () => `${product.value!.name} — Remiam`,
  description: () => product.value!.seoDescription,
  ogTitle: () => product.value!.name,
  ogType: 'website'
})
</script>

<template>
  <article v-if="product">
    <header>
      <EyebrowLabel :text="product.category" accent />
      <h1 class="type-display-xxl">{{ product.name }}</h1>
      <p class="type-body-lg">{{ product.pitch }}</p>
    </header>
  </article>
</template>

Why we keep coming back to it

"

We use other frameworks when the brief demands them — NativeScript for mobile, Wordpress for marketing-team-managed sites, raw Node for hardware-side services. But for most things, Nuxt is still the answer we don't talk ourselves out of.

Where we reach for something else

• 01Mobile-first apps with very deep native API access — NativeScript, sometimes React Native, sometimes Capacitor.
• 02Marketing sites where the client's team must edit every page without engineering — Wordpress.
• 03Hardware-bridge services that don't need a UI at all — raw Node, occasionally Go.
• 04Heavy data-warehouse / analytics workloads — a Python stack with FastAPI on the front.
• 05Anything where the client's existing team is React-native and ownership matters — Next.js.

For most things, Nuxt is still the answer we don't talk ourselves out of. The ecosystem keeps growing the right way, the team behind it ships regularly without breaking everything, and the patterns we've built up over a decade still work in the latest version.