Why I Moved from React to Vue (and What I Learned Going Back)

I started with React in 2019, moved to Vue when I joined a team in Dubai that used Nuxt, then came back to React for a client project, then back to Vue for my current work. Five years of bouncing between ecosystems taught me something the framework wars never will: the differences that generate the most Twitter arguments matter the least in production.

How I Ended Up in Vue

When I joined Nathan Digital in Dubai, the stack was Nuxt.js. I had zero Vue experience. The transition took about two weeks to feel productive and a month to feel fluent.

What surprised me wasn't the template syntax or the Options API. It was how much less I had to think about. In React, I'd accumulated a mental checklist for every component: memoization, dependency arrays, stale closures, ref forwarding. In Vue, reactivity just worked. I changed a value, the template updated. No useCallback wrapping, no useMemo decisions.

<script setup lang="ts">
const count = ref(0)
const doubled = computed(() => count.value * 2)

function increment() {
  count.value++
}
</script>

That's it. No rules of hooks, no dependency arrays to get wrong. The reactivity system tracks dependencies automatically.

What React Does Better

After eighteen months in Vue, I took a React project, a trading platform for a Norwegian client, and noticed what I'd been missing.

The ecosystem depth is real. React's library ecosystem is significantly larger. For niche requirements (complex data grids, virtualized lists, specific animation patterns), React almost always had a mature, well-maintained option. Vue's ecosystem has improved dramatically, but for enterprise-scale needs, React still has more choices.

JSX is genuinely flexible. When you need to compose UI dynamically (conditionally wrapping components, building render functions based on runtime data), JSX gives you the full power of JavaScript. Vue's template syntax handles 90% of cases elegantly, but the remaining 10% sometimes requires render functions that feel like fighting the framework.

TypeScript integration is tighter in React. Props are just function arguments. Generic components are straightforward. Vue 3 with <script setup> has closed this gap significantly, but React's TypeScript story has had more time to mature.

What Vue Does Better

Reactivity without ceremony. Vue's reactivity system is genuinely easier to reason about. You don't need to think about when things re-render because the framework handles it. In React, understanding re-renders is practically a prerequisite for writing performant code.

Single-file components are underrated. Having template, script, and styles in one file with scoped CSS isn't just convenient. It enforces a level of component cohesion that React projects often lose as they grow. Each component is a self-contained unit.

The official ecosystem is cohesive. Vue Router, Pinia, Vue DevTools, Nuxt. They're all designed to work together. In React, you're assembling your own stack from independent libraries that may or may not play nicely together.

The Differences That Don't Matter

After working production apps in both:

• Performance is equivalent. Both are fast enough for any application you're likely to build. The bottleneck is always your code, not the framework.
• Component patterns converge. Composition API and hooks solve the same problem in remarkably similar ways. Once you understand one, the other feels familiar.
• Build tooling is the same. Vite powers both ecosystems now. The DX is identical.
• Testing approaches are identical. Component testing, integration testing, E2E. The strategies and even the tools (Vitest, Playwright) work across both.

What Actually Matters

The framework choice matters less than:

1. How well the team knows it. A team fluent in Vue will ship faster in Vue than in React, and vice versa. The learning curve cost is real.
2. The ecosystem fit for your specific needs. If you need a specific library that only exists for one framework, that's your answer.
3. The meta-framework. Nuxt vs Next.js is a more consequential choice than Vue vs React because it determines your rendering strategy, deployment model, and server capabilities.
4. Consistency within the codebase. The worst outcome is mixing paradigms. Pick one and commit.

Where I Am Now

I primarily work in Vue and Nuxt. Not because Vue is objectively better (it isn't, in any absolute sense) but because the reactivity model matches how I think, the single-file component structure keeps my code organized, and Nuxt gives me everything I need in one coherent package.

If a project required React, I'd switch without hesitation. The skills transfer. The patterns transfer. The debugging instincts transfer. After five years, I've stopped thinking of them as competing frameworks and started thinking of them as different dialects of the same language.

The best framework is the one your team ships quality software in. Everything else is preference dressed up as principle.