We get asked fairly often, usually by a technical stakeholder on the client side, why we chose React for one project and Vue for another, expecting a technical answer about virtual DOM performance or ecosystem maturity. The honest answer is usually more mundane.
The question we actually ask first
Before any discussion of hooks, reactivity systems, or bundle sizes, the first question we ask is who maintains this after we hand it off. If the client's own team will maintain the code after launch and already has React developers, we build in React, full stop — a technically superior choice that nobody on the client side can maintain is not actually a good choice, it is a liability we are handing the client along with the finished product. We have seen this go wrong before we adopted this discipline explicitly: a project built in the framework we personally preferred, handed off to a client team fluent only in the other one, that atrophied into an unmaintained, increasingly outdated codebase within a year because nobody on staff could confidently touch it.
Where technical merit actually does tip the decision
That said, team fit is not the only factor, and there are real technical differences that occasionally do tip a decision:
- For a project needing a very large, sprawling single-page application with dozens of interdependent views, React's ecosystem of state management options (we lean on Redux for these) gives us more established patterns for genuinely complex state than Vue's ecosystem currently offers at the same level of documented convention
- For a project needing to move fast with a small, tight team and minimal boilerplate, Vue's lower ceiling for setup complexity and its more opinionated single-file component conventions usually get us to a working product faster, particularly with a team that is not already deeply fluent in either
- For a project that needs to integrate incrementally into an existing server-rendered application, dropping in isolated Vue components tends to be a gentler, less invasive migration path than introducing React into the same kind of legacy template structure, mostly due to how naturally Vue's templating syntax sits alongside existing HTML
What we tell clients who ask "which one is just better"
On pure technical merit the two are close enough for the vast majority of projects that the deciding factors end up being team fit, existing investment, and how quickly we need to ship — not which framework wins a benchmark. We try to be honest with clients about this rather than manufacturing a more decisive-sounding technical justification after the fact, since clients who hear "the frameworks are both good, here is why this one fits your situation" tend to trust our recommendation more than clients who sense we are overselling a technical difference that would not actually matter much to their project.
A recent example that illustrates the point well
A recent client came to us set on React because "that's what everyone uses," having read exactly that on a few industry blog posts, despite having a small internal team with prior Vue experience and no React background at all. We walked through the actual tradeoffs with them directly, including being candid that their own team's existing Vue familiarity was worth more to their long-term maintenance costs than whatever perceived popularity advantage React currently has in general industry conversation. They chose Vue, the project shipped on time, and their team has been maintaining and extending it confidently ever since — which is, at the end of the day, the actual measure of success we care about more than which framework got chosen.