---
title: "Why we use Nuxt for almost everything we ship."
date: 2021-10-08
url: https://remiam.co.uk/notes/why-we-use-nuxt-for-everything
tags: [Nuxt, Vue, Architecture]
read_time_minutes: 9
description: "Why Remiam reaches for Nuxt by default — SSR, server APIs, file-based routing, the module ecosystem that suits operational systems and brand sites alike, and where we still reach for something else."
---

# Why we use Nuxt for almost everything we ship.

*Published 2021-10-08 · 9 min read · by Liam (Remiam)*

Nuxt isn't trendy. It's just the right shape for the systems we tend to build — operational, content-heavy, SSR-first, with realtime in the corner. After 30+ production projects, here is the full case, the patterns we default to, and the brief categories where we still reach for something else.

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

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

## What it doesn't

- Hot reload still occasionally gives up the ghost on complex projects.
- Some module APIs change between majors — budget for it.
- Complex client-only flows need careful import guards.
- Documentation occasionally lags behind feature releases.
- When 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.

```vue pages/products/[slug].vue
<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

| Brief shape | Why Nuxt fits |
| --- | --- |
| Content-heavy brand site | SSR + Nuxt Content + Nuxt Image, ranks immediately |
| Bespoke web product | Server APIs co-located with the UI, shared TypeScript types |
| Static marketing site | nuxt generate produces clean static HTML, deploys to anything |
| Realtime dashboard | Easy to wire Socket.io / Pusher into composables |
| Multi-tenant SaaS | Middleware for auth + tenant routing, server APIs for protected data |
| PWA / mobile-shell | @nuxtjs/pwa, Capacitor integration, single code base for web + app |

*Brief categories where Nuxt is our default answer.*

> 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

- Mobile-first apps with very deep native API access — NativeScript, sometimes React Native, sometimes Capacitor.
- Marketing sites where the client's team must edit every page without engineering — Wordpress.
- Hardware-bridge services that don't need a UI at all — raw Node, occasionally Go.
- Heavy data-warehouse / analytics workloads — a Python stack with FastAPI on the front.
- Anything 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.

## References

1. [Nuxt — official documentation](https://nuxt.com/docs)
2. [Vue.js — official documentation](https://vuejs.org/guide/introduction.html)
3. [Nuxt module library](https://nuxt.com/modules)