Nuxt
A quote that says Nuxt has already chosen Vue for you
The short answer
Nuxt is a framework built on Vue. Vue draws the interface; Nuxt adds what every real site needs anyway, which is routing, rendering, data loading and a project layout everyone recognises. It's open source and free. Choosing Nuxt chooses Vue, and choosing Vue for anything serious usually ends up here.
Somebody wrote Nuxt into a proposal and carried on, and now you're expected to approve it. It isn't a hosting company and it isn't a website builder. It's the framework that sits around Vue, which means the quote made two decisions and showed you one.
Nuxt is to Vue what Next.js is to React
That's the most useful sentence on this page, so it goes first. Vue is a library for drawing interfaces in a browser, and it deliberately stops there. It has no opinion about which URL shows which page, where your files go, or how data reaches a screen.
Nuxt answers all of those. It's the same relationship Next.js has with React and SvelteKit has with Svelte. Developers call it a meta-framework, which is a word for them rather than for you. On your side it means the hundred small decisions were made in public, the same way on every project that uses it.
It's open source under the MIT licence and free to use. The bill for a Nuxt site is hosting and people. The framework never sends you one.
What the visitor gets
Every request
A finished page, then a Vue app that takes over in the browser once it has arrived.
Vue
The part you hire for
The library that draws the screen and keeps it in step with the data. It does that, and on purpose it does nothing else.
Nuxt
The framework
Routing, rendering strategy, data loading, and where every file goes. The decisions Vue leaves open.
Its server engine
Included
Bundled in. It answers requests, runs any API routes the build needs, and is the thing that actually gets deployed.
Wherever you deploy it
Chosen late
A plain Node server, a container, or a serverless platform. The application code stays the same either way.
The conventions are the product
Ask what Nuxt actually gives you and the honest answer is defaults, not features. That sounds like a thin offer until you've paid for the alternative.
Routing comes from the folder. A file in the pages directory becomes a URL, and that's the whole configuration. Nobody maintains a list of routes and nobody forgets to add one.
Data loading has a shape. Nuxt's helpers fetch on the server while the page is being assembled and hand the result to the browser rather than fetching it twice. Getting that wrong by hand is why some sites flash empty for a second and then fill in.
And there's a place for everything: components, layouts, server routes, configuration. Nuxt imports your own components for you, so most files open at the first line of real work.
None of it impresses anyone until a new developer opens the project. A Nuxt codebase looks like every other Nuxt codebase, which is the difference between hiring a replacement and commissioning an excavation. Vue's own documentation points anyone who needs server rendering at a framework like this rather than at building one.
One application, three ways to serve a page
Most platforms make you pick a rendering approach once, for the whole site. Nuxt makes it a per-route setting, and that's worth knowing before you agree to anything.
By default a page is assembled into finished HTML before it reaches the browser, which is what a crawler and a phone on a weak connection both want. A screen behind a login can skip it, since nobody is trying to rank that.
Portability applies underneath too. The server engine comes with Nuxt rather than being bolted on, so one build can target a rented server, a container or a serverless platform. Ask whoever's quoting to name the target anyway, because the differences show up in caching and in the hosting bill rather than in the code.
| How the page is served | What the browser receives | What you have to run |
|---|---|---|
| Built ahead of time | Finished HTML, generated during the build. | File hosting. No server of yours involved. |
| Rendered per request | Finished HTML assembled on request, so it can be current or personal. | A running server, or a platform that starts one on demand. |
| Drawn in the browser | A near-empty page plus the code that fills it in. | File hosting again, and nothing readable until that code runs. |
Where it stops, and it isn't the size of the build
Nuxt runs large applications. The ceiling you meet first is almost never technical.
It's hiring. React has a much larger pool of developers than Vue does, and the local version of that gap is the one that decides anything. In a city with three Vue developers, a Nuxt codebase is a small hiring pool wearing a technical disguise. Check your own market rather than a global survey.
It's the surrounding parts. When a project needs something unusual, a scheduling widget, a particular charting library, a vendor's own drop-in component, it tends to exist for React first. Vue usually has an answer, and sometimes that answer is a wrapper one person maintains alone. Check it against your actual requirements.
And it's history. Vue 2 reached its official end of life at the end of 2023, and Nuxt 2, built on it, is out of support too. Moving an old Nuxt 2 site to the current version isn't an upgrade, it's a rebuild that keeps the content.
Vue on its own
A library that draws the screen. Routing, data and the build are yours to choose.
Vue plus chosen parts
Router, store and build tooling added one at a time, in a layout only your team knows.
Nuxt
Routing, rendering, data loading and folder structure settled before anyone writes a line.
Nuxt with modules
Login, images and content arrive prebuilt, and each one is a dependency you now carry.
You assemble it
It's assembled for you
- You assemble it
Vue on its own
A library that draws the screen. Routing, data and the build are yours to choose.
Vue plus chosen parts
Router, store and build tooling added one at a time, in a layout only your team knows.
Nuxt
Routing, rendering, data loading and folder structure settled before anyone writes a line.
Nuxt with modules
Login, images and content arrive prebuilt, and each one is a dependency you now carry.
- It's assembled for you
Who has to be available in year two
The framework gets chosen in a meeting. This is the question that decides whether the choice was any good, and it's rarely in the proposal.
A Nuxt site needs somebody who can read Vue. Not full time, but reachable, because a build that worked in March fails in October for reasons nobody chose. Name that person while you're still negotiating. It's either someone inside the business or a standing arrangement with whoever built it, and a folder of documentation is neither.
Modules are where the rest of the risk sits. A project usually picks up a handful for authentication, images, content or analytics, and each is code somebody else maintains on their own schedule. Ask for that list in writing at handover. It's the honest inventory of what the site depends on, and nobody volunteers it.
If nobody will be available, that isn't an argument against Nuxt in particular. It's an argument against owning a codebase at all, and a platform your team can edit will serve you better than any framework.
Worth knowing before you start
Ask which major version the build will be on, and if you're inheriting a site, which one it's already on. Nuxt 2 and current Nuxt differ enough that a quote to change the old one is usually a quote to rebuild it.
Ask for the list of Nuxt modules the project will use, what each does, and who maintains it. A handful is ordinary. A long list means every upgrade waits on the slowest maintainer on it.
Ask which routes get built ahead of time and which get rendered per request. If that's a one-minute answer, somebody thought about search and speed before the build. If it's a shrug, nobody did.
Before you accept Vue by accepting Nuxt, search your own city's job boards for Vue roles and for React roles. That ratio is your real maintenance risk, and it varies far more between markets than any national figure suggests.
Common questions
No. Vue is the library that draws the interface. Nuxt is the framework around it, supplying routing, rendering, data loading and project structure. You can use Vue without Nuxt. You can't use Nuxt without Vue, which is why a quote naming one has settled the other.
No, and for a small interface dropped into an existing page you shouldn't. For a whole site the parts Nuxt supplies are needed anyway, so declining it means assembling a private version of the same thing. That's the right call when your requirements are genuinely unusual. The cost is that only your own team knows the layout.
It removes one common obstacle. Pages are rendered into finished HTML by default, so a crawler reads them without running any code first, which is the failure mode that quietly sinks browser-only builds. It does nothing about ranking itself. A Nuxt page that isn't found has a content or structure problem.
Only if it was built that way. Nuxt has no editing interface of its own. Content usually lives in a separate system your team signs into, with the site reading from it. If the words were written into the code instead, every typo becomes a release, and somebody chose that.
The content moves and the build doesn't, which is true of every framework. Text and images come out of whatever system holds them. The Vue components, the routing and the server code get rewritten. So the thing worth getting right now is where your content lives, not which framework renders it.
Related
Want to talk through your situation?
A short call is usually enough to tell whether this is the right work for you. If it isn’t, we’ll say so.