← read more

Nuxt 3 in Practice: What We'd Tell a Team Starting a Project Today

We build our own site on Nuxt 3 with @nuxt/content, and it's the stack we reach for when a project is mostly content with app-like corners. Where it earns its keep, where the framework gets in the way, and what we'd check before committing to it.

Nuxt 3 in practice: what we'd tell a team starting a project today

The site you're reading this on is Nuxt 3. We chose it because this site is mostly content: a marketing site, a blog, a few product pages, all of it needing to be fast, indexable, and cheap to edit. Nuxt handles that well, and it also handles the parts that aren't content, so the whole thing lives in one codebase. Having shipped client work and our own projects on it, here's what we'd tell a team evaluating it.

Where it actually earns its keep

  • Content rendering is a genuine feature. With @nuxt/content, a markdown file with frontmatter becomes a typed route with SEO, sitemap entries, and navigation for free. This blog is a directory of .md files plus a single dynamic route. Publishing a post is a commit; there's no CMS to maintain and no admin panel to build. For any product whose content is mostly written text, that alone removes a week of work.
  • The server output is small and boring. npm run build produces a Node server you can run under a process manager behind nginx, or static output you can put on any host. Either way, there's no separate SPA bundle to serve and hydrate carefully — the first paint is real HTML.
  • Vue ergonomics carry over. The Vue 3 composition API, <script setup>, and the component ecosystem all work as expected. A team that already knows Vue from other projects doesn't need to relearn the framework to use Nuxt.

Where it gets in the way

Honest list, from experience:

  • Client-side routing state is easy to get wrong. The hybrid model (server-rendered HTML plus client navigation) has its own cache layers for page data. On a news site we hit bugs where a page looked stale for some users and fresh for others, and the cause was a router cache option, not the CMS. Read the rendering-mode docs properly before setting ssr, routeRules, and prerender flags; the defaults are reasonable but they're defaults, not guarantees.
  • Version bumps are not ceremonial. Nuxt 3 minor releases have moved composables and changed module behavior. Pin your versions, read the changelog before upgrading, and don't ship an upgrade inside a feature PR.
  • Modules are a commitment. Sitemap, robots, SEO meta, image optimization — each one is official but imperfect. When the docs run out, you end up reading module source to learn, which is fine for us and a real cost for a team that just wanted a sitemap.

None of these are disqualifying. They're the difference between "the framework works" and "the team has read how it works."

The build choices we'd redo the same way

Three decisions shaped the project more than anything else. First, committing to file-based content from day one meant no migration pain later — the CMS-shaped products we considered early on all wanted to own the rendering. Second, pinning the sitemap and robots setup in the Nuxt config rather than hand-maintaining XML files means new pages are indexed without a manual step; we wrote about the rest of that pre-launch plumbing in the technical SEO checklist. Third, keeping the whole site in one deployment (build, upload, restart the Node process, done) means shipping a change takes minutes and can't get out of sync between "site" and "blog" — the same philosophy as our CI/CD piece, applied to a smaller stack.

When to pick Nuxt, and when not to

Pick it when the project is content-heavy with interactive parts: marketing sites, docs, blogs, product sites with pricing and a demo. The content pipeline plus server rendering beats assembling five tools for that shape. Also consider it when the team already speaks Vue, since the transfer cost is low.

Don't pick it when the product is an app first — dashboards or tools behind login, where SEO doesn't matter, and where Laravel + Inertia (our usual default) gives you the backend structure, auth, and queues that a content framework doesn't. And don't pick it because another team did; run the decision on the page shapes you actually have.

For the projects that fit, Nuxt 3 has been the rare framework we didn't fight. That's the most we can say about any of them.