How to judge a quote that builds your product in Vue

What kind of thing Vue is

Vue is an open-source JavaScript framework for building the part of a product people see and click. Buttons, forms, tables, anything that changes on screen without a page reload. It doesn't store your data, handle payments or run your server.

It's been around since 2014, it's free under an open licence, and it has no corporate owner, where React has Meta and Angular has Google. That independence cuts both ways, and which way depends on how long you expect the product to live.

One version fact matters most. Vue 3 is the current major version, and Vue 2 stopped getting free security updates at the end of 2023. If you're inheriting a build, ask which one you're getting.

One file per piece of the interface

Vue is built around the single-file component: the markup for one piece of the interface, the behaviour behind it and its styles, in one file. A search box is a file. The header is a file. The markup is ordinary HTML with extra attributes.

That sounds like housekeeping and it isn't. When something on screen is wrong there's one place to look, and the styles in that file apply nowhere else, so the fix that quietly breaks another page gets rarer.

One catch. Vue has two ways of writing the behaviour half, the older Options API and the newer Composition API. Both are current and either is fine. A codebase using both at random, because nobody decided, is what costs you at handover.

The middle path is a position, not a compromise

React and Angular sit at two ends of a range. Vue is the middle.

React gives you the rendering and leaves the rest open. Routing, shared state, build setup: all picked from a large ecosystem, per project. The flexibility is real, and two React codebases can share almost nothing but the library.

Angular goes the other way. Routing, forms, structure and TypeScript come with it, along with opinions about how code is organised. Every Angular project resembles every other, which is the point and a lot of framework for a small application.

Vue ships an official router, an official store for shared state and official build tooling, documented in one place by the same team. You can swap any of it and most teams don't, so two Vue codebases tend to resemble each other and somebody new has less of your arrangement to learn.

Nuxt is the part that finishes it

Vue on its own builds what runs in the browser. A visitor gets a mostly empty page and Vue fills it in. Behind a login nobody notices. For anything you want found in search, you pay to work around it.

Nuxt is the framework built on top of Vue that answers that. Pages render before they reach the browser, folders become URLs, and a library of add-ons covers the usual jobs. It's roughly what Next.js is to React.

It isn't free. A page rendered before it arrives needs something doing the rendering, so hosting becomes a running service rather than a folder of files. And you keep two things current instead of one.

So the question isn't Vue or Nuxt. It's whether this product needs what Nuxt does.

Where it stops, and it isn't performance

Nearly anything you can build in React you can build in Vue, and the speed difference won't decide whether your product works. The ceiling is somewhere else.

It's at the edges of the ecosystem. A heavy data grid, a charting library, the widget your payment provider hands you: the React version more often exists first and has the most questions answered. A Vue equivalent usually exists, sometimes as a wrapper one person maintains in their spare time.

The other edge is mobile. If the plan includes a native app sharing work with the web app, React Native is the well-travelled route. Vue reaches mobile by other means, with fewer people ahead of you.

Both are checkable in an afternoon before you commit, and expensive to find out after.

Who has to be around in year two

Vue doesn't create an operations job. No server of yours to patch, no platform bill attached. What it costs is people. It asks what every framework asks: who maintains this once the build is finished.

The pool of Vue developers in North America is smaller than React's, and public developer surveys put React use well ahead. That's not a judgment about the code. It's arithmetic about how long your next hire takes, and what happens the week the one person who knows the codebase resigns.

There's a counterweight. The template is close to what they already write, so a developer who knows JavaScript, HTML and CSS picks Vue up quickly. The constraint isn't that Vue people can't be found. It's that nobody wants to pay for two weeks of somebody learning.

The maintenance story should pick the framework, not the other way round. If you intend to staff this in-house eventually, that's a real argument for React with nothing to do with the code. If an outside firm will hold it, that argument mostly disappears.