React, Vue or Something Simpler? How I Choose a Frontend Stack in 2026

I do not start a new project by asking whether React or Vue is better.

I start with a simpler question:

What problem are we solving, what already exists, and who has to maintain it after launch?

Framework discussions can easily turn into comparisons of syntax, popularity or personal preference. Those things matter sometimes, but they are rarely what decides whether a real project succeeds.

I have worked on finance application journeys with Vue and Nuxt, newer SaaS products with React and Next.js, and client websites using platforms such as WordPress and Webflow.

The more projects I work on, the less interested I am in picking a framework winner.

I care more about choosing the option that gives the product the best chance of staying reliable and understandable six months or several years later.

If there is already a stack, I need a strong reason to change it#

If I join a mature Vue application with reusable components, tests and developers who understand the codebase, I am not going to introduce React just because React is popular.

Now the product may have:

• two component approaches;
• different state patterns;
• additional tooling;
• more knowledge required across the team;
• potentially duplicated UI and testing approaches.

Sometimes migrations are justified.

But another framework being more popular is not enough.

For an existing product, consistency and delivery risk often matter more than framework preference.

Where Vue has worked well for me#

My deeper commercial frontend experience is with Vue and Nuxt.

One area where I have found Vue especially effective is complex, form-heavy product work.

A finance journey is a good example.

Imagine a customer selects self-employed, enters a business name and ABN, then goes back and changes their employment type to employed.

The inputs disappear from the screen.

That does not necessarily mean the problem is solved.

If those old values remain in shared state, they may still end up in an API payload.

The fix is not simply hiding two inputs.

Irrelevant state needs to be dealt with deliberately, and the mapping layer should only send fields that remain valid for the customer's current answers.

This is the kind of problem where I like Vue's reactivity model, computed state and Composition API.

But there is another lesson in that example:

not all state belongs in Pinia.

Local interface state can stay local.

Derived values can be computed.

Reusable behaviour can live in a composable.

URL filters may belong in the router.

Shared workflow state may justify Pinia.

Server data has another lifecycle again.

State management is really an ownership decision.

Where React and Next.js have worked well for me#

For newer SaaS work, I have increasingly been using React and Next.js.

Pagelyze is one example.

It deals with website audits, findings, asynchronous processing, reports, persisted application data and browser-based checks.

Horse Syndicate is also built around Next.js and TypeScript, but its domain is very different: syndicates, ownership records, effective-dated changes, expenses, statements and scheduled reminders.

What I like about React is its compositional model and ecosystem.

Next.js then gives an application framework around React rather than requiring every application-level concern to be assembled independently.

But neither React nor Next.js fixes bad architecture.

• A component can still own too much.
• API data can still be duplicated into unnecessary state.
• Failure states can still be forgotten.
• Business logic can still be buried inside presentation components.

The framework helps.

Engineering judgement still matters more.

What does Vue do better for me?#

Vue remains the frontend ecosystem where I have deeper commercial experience.

For complex product interfaces, I often find its templates, computed state, reactivity and Single-File Components easy to reason about.

Vue also provides a fairly cohesive ecosystem around routing and state.

React provides more freedom.

Sometimes that flexibility is exactly what a product needs.

Sometimes it means a team needs stronger conventions because there are more architectural decisions available.

I do not consider one objectively better.

They optimise for somewhat different developer experiences.

So how do I choose?#

For a new product I normally look at these before worrying about syntax.

1. Existing technology#

What does the organisation already operate?

What can the team confidently build and support?

2. Product shape#

Is this:

• a SaaS application;
• a multi-step workflow;
• a marketing website;
• an ecommerce store;
• an internal tool;
• a content platform?

Those are different problems.

3. State complexity#

Is most state local?

Do we have a long multi-step workflow?

Is the difficult problem really frontend state, or is it server data and domain modelling?

4. Team and hiring#

A technically elegant solution is not useful if maintaining it becomes unnecessarily difficult.

5. Integrations#

Existing APIs, CMS platforms, commerce systems or specialised libraries can materially influence the decision.

6. Delivery risk#

How much extra complexity are we introducing?

That last question matters more to me now than it did earlier in my career.

Sometimes I choose neither React nor Vue#

Framework comparisons often miss this.

For client work, the right answer can simply be:

• WordPress;
• Webflow;
• Shopify;
• the CMS that is already there.

I have worked on AGMS content and CMS improvements in Webflow.

Rebuilding that type of website as a custom React application simply because React is considered more modern would not automatically improve the business outcome.

If the main requirements are:

• reliable pages;
• editable content;
• good mobile behaviour;
• clear enquiry journeys;
• good performance;
• straightforward maintenance;

then keeping the CMS may be the better architecture.

Senior engineering is partly knowing when not to build more software.

That is also why PKTechie keeps dedicated services for practical web delivery and WordPress, Shopify and Webflow fixes, rather than forcing every business into a custom application path.

AI is changing this decision, but not in the way people think#

This is becoming one of the more interesting parts of frontend engineering.

AI does not suddenly make React better than Vue.

What AI is changing is how applications are designed, built, tested and maintained.

Development is moving beyond simple code completion.

That makes engineering discipline more important, not less.

If an AI coding agent can modify many files quickly, then the quality of the surrounding system becomes critical:

• clear architecture;
• useful tests;
• documented contracts;
• predictable boundaries;
• observability;
• reviewable changes.

AI can produce code quickly.

It still needs a system where correctness can be checked.

I have written about a simpler version of this idea before: AI will not help much if the basic product journey is already broken.

AI changes product architecture too#

For an AI-enabled product, I normally think about the frontend and AI system as separate concerns.

The frontend may need to present:

• streaming output;
• long-running task status;
• evidence and citations;
• tool activity;
• approval steps;
• retries;
• partial failures.

But some of the harder engineering questions are behind that UI:

• What data is the model allowed to see?
• What tools can it call?
• What happens when its answer is wrong?
• How do we evaluate output quality?
• When does a human need to approve an action?
• Can we trace why a result was produced?

That is why I would never choose React simply because somebody says:

We are building an AI product.

Vue can build that interface too.

The bigger architecture decision is around the AI boundary.

Pagelyze is where this becomes practical for me#

Pagelyze already collects deterministic evidence from websites.

That distinction matters.

If a browser check can establish whether something exists, failed or behaved in a certain way, I want deterministic software to establish that evidence.

I do not want an LLM inventing the fact.

AI becomes interesting after reliable evidence exists.

That is a direction I am increasingly interested in.

Not replacing engineering with AI.

Using deterministic software for facts and AI where reasoning genuinely adds value.

Human review is not disappearing#

There is a lot of attention around autonomous coding agents.

I think the more practical pattern today is controlled delegation.

Agents can help:

• investigate codebases;
• trace problems;
• propose changes;
• run tests;
• prepare implementation work.

Humans still need to judge:

• whether the requirement was understood;
• whether the architecture remains sensible;
• whether a test proves the right behaviour;
• whether security or business rules were missed.

I expect judgement to become a larger part of senior engineering, not a smaller one.

So what would I choose today?#

I would lean towards Vue/Nuxt when:#

• the product already uses Vue;
• the team has strong Vue experience;
• the interface has complex reactive workflows;
• its conventions reduce unnecessary decisions.

I would lean towards React/Next.js when:#

• the organisation already uses React;
• Next.js fits the product and deployment model;
• the ecosystem provides something valuable;
• the team is productive with it.

I would choose a CMS when:#

• the problem is primarily content, ecommerce or lead generation;
• editors need direct ownership;
• a custom frontend would add cost without proportional value.

For an AI product?#

I would still choose the frontend framework using normal engineering criteria.

Then I would spend considerably more time thinking about:

AI boundaries, tools, evaluation, observability, security and human control.

Final thought#

A few years ago, choosing the frontend framework could feel like one of the biggest architecture decisions.

It still matters.

But in 2026, another question is becoming just as important:

Can we build software that stays understandable and trustworthy when both humans and AI agents contribute to it?

That changes what I value.

• Clear boundaries.
• Good tests.
• Simple state ownership.
• Observable systems.
• Useful documentation.
• Knowing when not to introduce another layer.

React and Vue are both good tools.

The senior decision is knowing which tool fits the system - and increasingly, designing that system so both humans and AI can work with it safely.