When we started this project we did the honest thing and listed the boring requirements first: fast initial loads, good SEO, a comfortable developer experience, and a path to static hosting so the marketing site could live cheaply on a CDN. Several frameworks could tick those boxes. Nuxt ticked them while staying close to plain Vue, and that proximity is ultimately why we chose it.
Rendering on our terms
We did not want to commit to a single rendering strategy up front. Nuxt lets us server-render where freshness matters and statically generate where it does not — sometimes within the same project. This marketing site is fully pre-rendered to static files, but the same codebase could serve dynamic routes the day we need them, without a rewrite.
- Static generation for content that changes on our schedule, not the user's.
- Server rendering kept available for anything that must reflect live data.
- One mental model for both, instead of two stacks bolted together.
Conventions that remove decisions
File-based routing, auto-imported components and composables, and a predictable project layout mean there are fewer trivial decisions to make and fewer ways for two engineers to disagree. The framework has an opinion, we adopt it, and we spend our judgement on the product instead of on plumbing.
The best thing a framework can do is make the obvious choice the easy one, and then get out of the way.
What it cost us
No choice is free. A meta-framework adds a layer to understand when something goes wrong, and the auto-import magic occasionally hides where a function actually comes from. But the failure modes have been shallow and well-documented, and the time we save on routing, data fetching, and build configuration has comfortably outweighed the occasional detour into the docs.
A year in, we would make the same call again. Nuxt gave us the conventions of a full framework without pulling us away from the Vue we already knew — and that balance is exactly what a small team needs to ship.