A supplier has handed you a Vue application, and nobody has said whether that means Vue 2 or Vue 3.
For a new build, Vue 3 can be a clear and proportionate way to create an interactive frontend. An inherited Vue 2 product is a different decision. Vue 2 stopped receiving fixes at the end of 2023, and the cost of moving depends on the components and packages gathered around it.
The framework name is not enough for an approval. Ask which generation you own, which application decisions sit outside Vue and who can maintain the result.
“Vue is easier to pick up” needs a maintenance test
Vue’s templates look close to HTML, and its single-file components keep markup, logic and component styles together. That makes the first part of the learning curve approachable for teams coming from server-rendered pages.
The official Vue introduction also describes a progressive path: it can enhance static HTML, power embedded components or run a full single-page application. The pitch is fair. A project can adopt the amount of Vue it needs instead of rebuilding every page.
Ease of entry does not answer who will own a large codebase in three years. Ask how many people can review the Composition API, router, state and build setup used in this project. A smaller local hiring pool may be fine when the team is stable. It becomes material when the application will be handed between suppliers.
Vue 2 end of life turns an old app into a migration
Vue 2 reached end of life on 31 December 2023. The project states that it receives no new fixes, while paid extended support is available for organisations that cannot move yet. The Vue 2 end-of-life notice is unusually direct about the security and compliance conversation this creates.
Do not estimate a Vue 2 to Vue 3 migration from component count alone. The audit needs Vue Router, Vuex, Nuxt, UI libraries, test tools, class-style components and every package pinned to the old generation. Custom directives and undocumented behaviour can add more work than the visible templates.
Vue provides a migration build that can run much of a Vue 2 application in a Vue 3 mode while producing compatibility warnings. It is a bridge, not evidence that every dependency has a maintained Vue 3 route.
Vue itself does not settle routing or server rendering
Vue is the interface layer. A production application may also need routing, data loading, server rendering, authentication boundaries and an approach to code splitting.
The Vue guide recommends Vue Router for most single-page applications. Its server-rendering guide points developers towards Nuxt when integrated server-side rendering is required because building that stack by hand carries more complexity.
Decide this before approving “Vue” as the architecture. A focused authenticated dashboard can work well as a client-side Vue application built with Vite. A public product with many content routes and server-side data needs may be a Nuxt decision. The delivery and hosting models differ.
Composition API helps only when the team agrees how to use it
Vue 3 supports the Options API and Composition API. Both are valid, and existing Options API components do not need rewriting for fashion.
The Composition API makes it easier to group related logic and extract reusable functions from complex components. It can also scatter simple component behaviour across many composables if the team has no boundary for what gets extracted. Vue’s own Composition API FAQ frames the benefit around logic reuse, code organisation and TypeScript integration rather than declaring the older style obsolete.
Ask for one convention and examples. A mixed codebase is manageable when the rule is deliberate. A different style in every component transfers learning cost to each person who touches it.
A Vue dependency audit matters more than framework popularity
Vue 3 is active and well supported. The risk in an inherited application usually sits in its surrounding packages and the assumptions made by the original build.
List the version, maintainer and replacement route for every direct frontend dependency. Check whether the UI library still supports the current Vue line, whether tests cover the components it owns and whether the project can reinstall from its lockfile. A Vue 2 application that only works with an old node_modules directory is already telling you the upgrade estimate is uncertain.
Popularity surveys can inform hiring and ecosystem confidence. They cannot show whether a specific charting package, editor or authentication plugin blocks your migration.
Questions to put to a team proposing Vue
- “Is this Vue 3, or are we inheriting Vue 2?” Treat them as separate approvals.
- “Which parts of the product need Vue at all?” Progressive enhancement may be enough.
- “Are routing and rendering handled by Vue Router, Nuxt or the server application?” Name the architecture.
- “Which component and state conventions will the team follow?” Ask for working examples.
- “Which dependencies would block a Vue 3 or Node upgrade?” Review the package audit.
- “Can we reinstall, test and build the project from a clean machine?” Prove the handover path.
- “Who can maintain this after the current supplier leaves?” Match the framework to the ownership plan.
When Vue 3 is the proportionate frontend
Vue 3 is a sensible choice for an interactive application when the team knows it and the architecture remains focused. It works particularly well for adding substantial components to an existing Laravel or server-rendered product without forcing the whole site into a client-side application.
It also suits a new dashboard or internal tool where Vue Router and a small state layer cover the need. The approval becomes easier when the team has agreed component conventions, TypeScript checks and a current build pipeline.
For a Vue 2 product that earns money, a staged migration can be justified. Secure the current release, audit dependencies, introduce the compatibility build and move tested areas without freezing all feature work.
When another frontend decision should come first
Do not adopt Vue because its templates look friendly if the organisation already has a maintained frontend stack and no Vue ownership. Reuse of skills, monitoring and components can outweigh a developer’s local preference.
Avoid a full Vue application when a handful of browser behaviours would solve the requirement. Server-rendered HTML with small progressive components ships less JavaScript and creates fewer application-level decisions.
And do not hide a Vue 2 rescue inside a feature estimate. If the old dependency graph needs replacement, price and approve that migration openly. Paid extended support may buy planning time, but it does not turn the old stack into a current product foundation.
Vue 3 is a sensible choice. Vue 2 is a migration plan.
I will approve Vue 3 for a focused interface when the team can maintain it and the application does not need a bigger framework decision. An inherited Vue 2 codebase gets a dependency audit before anyone promises an upgrade date. I care more about the route out of old packages than whether another framework is fashionable.
Alexander De Sousa · Founder, Digital Royalty · LinkedIn
What decides whether Vue is an asset or inherited work
Version, application shape and maintainers matter more than the framework label. These are the facts I would want before accepting the estimate.
The Vue decision in six ownership questions
- Role in the stack
- A progressive UI framework. It can enhance server HTML or run a client-side application, while routing and rendering need explicit choices.
- Customer effect
- Reactive interfaces and faster in-page interactions. Rendering strategy and shipped JavaScript still determine much of the public experience.
- Adoption cost
- Low for a clean Vue 3 component. A Vue 2 migration varies with UI libraries, build tooling, Nuxt generation and custom component patterns.
- Ongoing owner
- Frontend maintainers who own Vue, router, state, dependencies, tests and the Node-based build pipeline as one supported system.
- Exit cost
- Moderate. Business APIs and plain JavaScript can travel; components, stores, directives and framework-specific packages need replacement.
- Proof required
- A clean install and production build, a dependency inventory and a trial of the riskiest route or component on the intended Vue 3 stack.
Routes that belong in a Vue frontend discussion
-
Keep server-rendered pages
Right when: The product needs a few interactive behaviours and its existing server-side rendering already handles navigation and data well.
Watch for: Avoid growing a collection of unrelated scripts with no component or testing convention.
-
Vue 3 with Vite
Right when: A focused client-side application needs components, routing and a fast current build without a server-rendered framework.
Watch for: The team still owns data loading, route boundaries, error handling and the production architecture around Vue.
-
Nuxt
Right when: The product needs integrated routing, server rendering, data fetching and deployment conventions around Vue.
Watch for: This adds a framework and server or build-time model. It is a larger commitment than adding Vue components to existing pages.
-
Vue 2 extended support as a bridge
Right when: A revenue-critical Vue 2 product cannot move immediately and compliance needs maintained security fixes while the migration is planned.
Watch for: Set an exit date and dependency plan. Paid support protects time; it does not remove the eventual migration.
What informed this Vue recommendation
-
Official guidance
Vue introduction and adoption modes
Vue documents its use from enhanced static HTML through to full applications. That supports choosing the smallest adoption mode that solves the requirement.
-
Official lifecycle
Vue 2 end-of-life notice
Confirms that open-source Vue 2 no longer receives fixes and explains the extended-support route for organisations that cannot move yet.
-
Official migration
Vue 3 migration build
Provides a compatibility mode and warning path. Its documented limitations make a dependency and feature audit necessary before estimating.
-
Official architecture
Server-side rendering with Vue
Vue documents the complexity of a hand-built server-rendered stack and points to Nuxt for a higher-level solution.
-
Developer survey
State of JavaScript 2025 front-end frameworks
Usage rankings were stable and Vue remained a mainstream choice. Survey sentiment gives ecosystem context, not a verdict on a particular codebase.
-
Practitioner question
Stack Overflow: auditing a Vue 2 dependency graph
A migration question centres on third-party library versions rather than Vue templates. That is the uncertainty an estimate should investigate first.
-
Community discussion
Reddit: production teams still on Vue 2
Developers report both manageable and difficult migrations depending on tests, dependencies and custom code. The disagreement supports a project trial.
Tell us what you need
A few quick questions, then a straight answer from a real person — usually within a few hours.
Tell us what you're working on
Whether it's a new site, a platform, or a process that shouldn't be manual any more — we'll tell you honestly if we can help.