Every team eventually faces the framework question. We faced it three times in the last two years, picking Vue each time. This is the opinionated, internal-style explanation of why, including the trade-offs we accepted and the few cases where we would still reach for something else.

Our constraints

To explain the decision, you need to know the constraints. Mangobaz is a two-person studio in Lahore. We work with founders and product teams on projects that range from one-week MVPs to six-month builds. Every project needs a front-end framework, and the choice is mostly sticky for the life of the codebase.

Our constraints: fast onboarding of new collaborators (contractors, designers who can read code), low boilerplate (we are paid to ship, not configure), good performance by default, and a single mental model that scales from a 200-line prototype to a 200,000-line application. Those constraints are not universal — for a different team they would point to different choices.

Why Vue, briefly

Vue's templating syntax is the closest thing to "just HTML with extra powers" that any modern framework offers. A designer who knows HTML can read a Vue template and follow it without learning a new language. JSX requires thinking in JavaScript. Vue templates require thinking in HTML, which most people already know.

The Composition API gives us the same composability and logic reuse as React Hooks, but without the rules-of-hooks trap (do not call hooks conditionally). Components stay readable as they grow. Reusable logic lives in composables, which are just regular functions.

The trade-offs we accepted

Picking Vue means:

  • Smaller talent pool locally. More developers know React than Vue. For hiring, this is a real cost.
  • Fewer pre-built components. The React component ecosystem (especially around shadcn/ui and Radix) is larger.
  • Slightly fewer integrations. Some libraries ship React-first and Vue-second. Usually fine, sometimes a small tax.

None of these have bitten us in a project-killing way. The talent pool constraint we manage by hiring developers who can learn (almost everyone can). The ecosystem gap we bridge by writing the few missing pieces ourselves.

Where we still reach for React

We are not dogmatic. Two cases where React still wins:

  1. Existing teams who already know it. If a client's in-house engineers have shipped React for years, fighting Vue onto them is a waste of everyone's time.
  2. Highly specialised React-native ecosystems. React Native for mobile, some ML visualisation tools. Vue's equivalents exist but are less mature.

For greenfield web work with a small, flexible team, Vue is our default.

The actual day-to-day difference

In a typical week, the difference shows up in three places:

  • Onboarding new collaborators. A contractor who knows HTML and a little JavaScript can be productive on a Vue codebase in days. The same person on a React codebase might take a week to internalise JSX and the hooks mental model.
  • Reading code. Vue templates read like enhanced HTML. You can scan a component and find what you are looking for without parsing a chain of React fragments and props.
  • Refactoring. Vue's options are clearer when you are reorganising a large component. Composition API code is just functions, which can be moved around easily.

None of this makes Vue objectively better. It makes Vue better for us.

The framework landscape is converging

It is worth noting that Vue 3 and React 18+ are converging on similar capabilities. Server components, signals, fine-grained reactivity — all in flight on both sides. The framework wars are quieter than they used to be. Pick based on team fit and ecosystem, not on a benchmark.

The history of our Vue adoption

We shipped our first Vue project in 2018, a small internal dashboard for a logistics company. Vue 2 was the current version. The team at the time was one full-stack developer and one designer. Vue made sense because the designer could read the templates without learning JavaScript.

Over the next three years, every new project used Vue. The codebase grew. We adopted Vuex for state management, then migrated to Pinia when it became the official recommendation. We rewrote the older components in Vue 3 when it shipped. None of these transitions were painful — Vue has prioritised backward compatibility and clean migration paths.

By 2022, Vue was the default in our studio. The two-person team knew the framework deeply. New collaborators could be productive in days. We had built a small library of reusable components and composables. Switching costs would have been high; the reasons to switch were low.

What makes Vue easier to teach

Watch a new developer learn Vue for the first time and you will notice something: they can be productive on day one. A component is a single file with template, script, and style. The template is HTML with a few directives (v-if, v-for, @click). The script is regular JavaScript with a few imports. The style is regular CSS. There is no JSX, no virtual DOM mental model required, no hooks rules to memorise.

React asks you to think differently — components are functions returning JSX, hooks have rules, state updates are scheduled. None of this is hard, but it is different. Vue asks you to extend what you already know. For mixed teams (designers who can code, junior developers, contractors), the lower barrier matters.

The case for Svelte

If we were starting fresh today, with no existing Vue codebase, Svelte would be a serious contender. Svelte 5 (released 2024) introduced runes, which give it the same fine-grained reactivity as Vue 3 or SolidJS, with even less boilerplate. The compiled-output model means smaller bundles and faster runtime.

We have not migrated to Svelte for two reasons. The ecosystem is smaller — fewer pre-built components, fewer integrations, fewer Stack Overflow answers. And our existing Vue code is solid; rewriting it would cost real money with no clear benefit. If you are starting a new project today, evaluate Svelte seriously.

The case for React

React is the right choice for many teams. The ecosystem is enormous, the talent pool is large, the documentation is good, and the framework is mature. We have shipped React projects when the client demanded it or when the team already knew it. There is no shame in picking React.

For our small, flexible studio, the lower barrier to entry of Vue templates wins out. For a 50-person engineering org with an existing React codebase, the inertia of staying with React wins out. Neither answer is wrong. The answer that is wrong is picking a framework because it is what someone on Twitter told you to use.

How we decide on a new project

The decision tree:

  1. Does the client have an existing codebase? Use whatever they have.
  2. Does the client's team have a strong preference? Use what they know.
  3. Is the project greenfield with no constraints? Default to Vue.

This is the entire framework selection process. If you are a freelancer or studio doing bespoke work for clients, almost every project falls into one of the first two buckets. The third bucket — pure greenfield — is rare, and that is when framework taste actually matters.

What we look for in a framework

When evaluating a new framework (or considering switching our default), we look at five things:

  • Documentation. Is there a clear, comprehensive, searchable reference? Vue's docs are the gold standard. Svelte's are nearly as good

    Further reading

    This article is opinionated, so we pair it with the documentation that informs the opinion. The two official framework sites and the most recent State of JS survey give you the data points behind our reasoning.

    • Vue.js official site — the Vue.js homepage and guide, including the case for Vue’s progressive, approachable design philosophy.
    • React official docs (react.dev) — the modern React docs — components, hooks, and the React mental model from the team that builds React.
    • State of JS survey — the annual developer survey that tracks frontend framework usage, satisfaction, and sentiment across the JavaScript ecosystem.
    . React's are fragmented between react.dev and the older docs.
  • Stability. Does the API change every six months? Vue 2 to Vue 3 was a major rewrite, but the migration path was clean. React 16 to 18 was incremental.
  • Tooling. Does a single command set up a project with a build tool, dev server, and type checking? Vite + Vue: yes. Vite + React: yes. SvelteKit: yes.
  • Community. Are there good answers to common questions on Stack Overflow and Reddit? Vue: yes, but smaller than React. React: yes. Svelte: yes but smaller.
  • Long-term viability. Is the framework backed by a company or foundation that will maintain it? Vue: yes, by a core team and many companies. React: yes, by Meta. Svelte: yes, by the Vercel ecosystem.

By these measures, Vue, React, and Svelte are all viable choices. The differences are smaller than the framework discourse suggests.

FAQ

What about Svelte?

Svelte is wonderful. Smaller, faster, less boilerplate. We would consider it for greenfield projects with a single developer. We have not used it in production because Vue's ecosystem is broader, and ecosystem matters at the studio scale.

What about SolidJS?

Solid is the performance champion. For highly interactive, real-time apps, it is technically the best choice. Smaller ecosystem, smaller community. We have not had a project that needed it yet.

Do you use Vuex or Pinia?

Pinia. Vuex was the old official state library. Pinia replaced it in 2022 and is what every new Vue project uses.

What is Nuxt?

Nuxt is the meta-framework on top of Vue, like Next.js for React. We use it for projects that need server-side rendering, file-based routing, and SEO out of the box. For internal tools and SPAs, plain Vue with Vite is enough.

Should I switch from React to Vue?

Probably not. The switching cost is high and the benefit is small. Pick the framework that fits your team and ship more things.

Whatever framework you pick, commit to learning it deeply. The depth matters more than the choice.

Whatever framework you pick, the principles are the same: small surface area, good documentation, mature ecosystem, and a team that knows it well. The specific name matters less than the discipline you bring.

The discipline of stating constraints first is more valuable than the framework you pick in the end.

The discipline of stating constraints first is more valuable than the framework you pick in the end. State your constraints, evaluate options against them, and commit to the choice.

Homework

No code this time. Instead, write down the framework constraints that matter most for your team: hiring pool, ecosystem, learning curve, performance, type safety. Then look at the three most popular options in your language and see which one best fits the constraints you wrote down. The discipline of stating the constraints first is more valuable than the framework you pick.