Proud Dad, Software Developer, Hobby Data Scientist, Degenerate Gambler. Follow me on Twitter, Medium or connect on LinkedIn.

When to use Vue over React

A highly opinionated article based on my experience as a front-end web developer over the last four years.

I use React professionally at my current job, but I choose Vue for all personal projects. It’s my preferred framework of choice. I’ve used Vue in previous (publicly traded) companies, and it scaled incredibly well.

Any seasoned developer will tell you software is all about trade-offs and throwing around objective statements like “Framework x is better than Framework y” are generally meaningless. By what metrics? In whose opinion? For this reason, I’ll compare Vue and React across three main concerns that are often competing trade-offs.

  1. Performance
  2. Scalability
  3. Job Market

Performance

Performance is usually where people want to start when discussing frameworks or languages. Everyone who writes software is building the next FAANG company, and every nanosecond of performance must be extracted from our code.

I’m going to compare both frameworks on two components of performance, namely silicon time and carbon time. Silicon time refers to the raw execution performance — how fast it can run in the browser. Carbon time refers to how fast developers can build products in the code.

Silicon-time comparison

JS framework trade-offs for performance JS framework trade-offs for performance

React leverages JSX, which gives developers a lot of power to build arbitrarily complex logic. We can harness the Turing-complete power of JavaScript and treat our view as data. Something like Svelte leverages templates for markup that provide a rigid structure to the view layer.

React and Vue both use a virtual DOM (VDOM), which, while practically fast enough, is inherently expensive and almost purely overhead. Svelte compiles template code to raw JS and manipulates the DOM directly, which means it doesn’t have the performance overheads of maintaining a VDOM.

What I love about Vue is it hedges its bets a little bit. The most common way to use Vue is to use templates in single-file components. This has allowed the Vue team to do some very clever things in the upcoming Vue 3 release with ahead-of-time (AOT) optimisations.

The structured nature of a templates means a compiler can know things about your code and perform optimisations. The main optimisation Vue introduces is dropping all static data from the VDOM diff. VDOM performance is directly affected by the number of nodes it has to track. By filtering out static data from this VDOM-diffing process, we can reduce the number of nodes being tracked. This makes the code run much faster as it doesn’t have to compare a recursive tree of arbitrary nodes at each render cycle.

While Vue appears to use templates in most cases, the compiler actually turns these templates into render functions for you under the hood. This means any time the templating of Vue is getting in your way, you can directly drop down and write render functions exactly like you would in React. This means you get all the flexibility of render functions and JSX that you get in React with some of the performance benefits you get from a templated framework like Svelte. Obviously, if you write a Vue application with 100% render functions, you lose all of the template optimisations.

Code benchmarks are a bit of a waste of time, in my opinion, but a few show Vue 2 around 2.5x faster than default React, and Vue 3 is benchmarking 3-5x faster than Vue 2. In practice, the JS framework you use is going to be such a small component of your application that these benchmarks are nearly meaningless. However, if you’re building templates that’ll leverage Vue 3’s AoT optimisations from templates, there’s just no way the same app will be faster written in React.

Winner: Vue

Carbon-time performance

Carbon cost versus silicon cost for software development Carbon cost versus silicon cost for software development

A senior developer will cost you around $150/hr depending on where you are in the world. Even junior to midlevel developers are earning a good enough salary that you want to be factoring in development time and costs into your technical stack. It’s the reason why languages such as PHP, Python, Node, Ruby, etc. are so popular and we don’t just write everything in C.

For front-end applications, we’re constrained by the browser, device resources, and network latency, so silicon performance is still a contributing factor — but carbon performance should also be at the forefront of any CTO’s mind.

In my opinion, the single greatest contributing factor in the success of Vue has been its approachable documentation, resources, and ease of learning. I learned React and Vue at the same time, and Vue was noticeably easier to get started with. If you know HTML, CSS, and the bare basics of JS, you can build an application with Vue. I’ve spent half a day with a design team and had them shipping changes to production front ends in Vue. This frees up a lot of time for the dev team and allows designers to implement A/B tests and design updates without getting blocked by the software backlog.

One of the things I love about Vue is the layered design of its opt-in tooling. You can start by pulling in Vue via a CDN. That means you can play with it without needing to go through complex build steps (webpack/Babel config, npm, etc). You can then progress to the Vue CLI and build basic apps. If you then need a state management solution, there’s an officially supported and documented solution in Vuex. Similarly, Vue Router is an officially endorsed and supported router solution for Vue.

On the other hand, React introduces the paradox of choice, which can make things hard for newcomers.

React is a small-scope, single-purpose library that introduces a component model that receives props and returns a VDOM tree. This provides a lot of flexibility and the React community has built many complex systems on top of this simple library.

There’s a large ecosystem with many, many options available to solve tasks. These are maintained independently by users. This model provides a lot of opportunities for people to build things on top of React and build popular libraries and tools.

It also makes things very difficult to find and learn. You’re stuck choosing the best option for state management or routing or configuring a new application. In my experience, this also makes hiring React developers harder. When there’s multiple ways to do things, onboarding new members to a React project has more friction than onboarding to a Vue project.

Winner: Vue

Scalability

Most of my thoughts on the scalability of these frameworks was touched on in the performance section. Scalability is often intrinsically linked with performance, so it’s not surprising.

I generally think of scalability in terms of:

Scaling the number of views/components/workflows in an application

In terms of scaling out the number of components, I’m a really big fan of the single-file component (SFC). The logical grouping of a component makes a lot of sense to me. Many people disagree with this, and it’s a matter of opinion rather than an objective statement.

The reason I love SFCs is because they provides a great way to enforce the separation of concerns (SoC).* *Some people argue that mixing HTML, CSS, and JavaScript is doing the opposite of separating concerns. I’ve changed the way I think about this principle on the front end, largely with my obsessive adoption of Tailwind CSS for styling my components.

Adam Wathan wrote a great articleon the notion of SoC and how it applies to HTML and CSS. I think about my front-end components in a similar way. In my mind, a component is how it looks (HTML/CSS) and how it works. Separating the markup from the JS feels arbitrary to me. If you consider your views as data, then (to me) it makes sense to group them with your data.

Don’t even get me started on JSX and CSS-in-JS. HTML and CSS are not dead. They’re incredibly powerful building blocks of the web. Use them!

The benefits of officially supported solutions to common problems also comes in handy at scale. If you’re having trouble scaling a Vue application, then chances are any other Vue application at scale has used the same architecture, and you’ll be able to find advice and help. You don’t need to worry about people saying, “Just use hooks/MobX/Redux/Redux-Saga.”

Scaling the number of developers on a team

I’ve already mentioned I’ve previously seen a design team empowered to push changes to production with a few hours of help. That’s an insane productivity boost to any consumer-facing application.

The general consensus that Vue is easier to learn also means you can train junior developers to a point of net benefit to the team much much faster. You can also onboard a React developer (assuming they know HTML and CSS) with little effort.

Again, having consistent solutions to common problems makes code review and reasoning about a large codebase that much easier for everyone on the team.

The key thing with both of these is maintaining development velocity while keeping a performant application that meets the needs of your users. Vue strikes the perfect balance here as far as I’m concerned.

Winner: Vue

The Job Market

OK, so I’ve convinced you Vue is better than React in every conceivable way. But this is meaningless if you can’t get paid (or find devs to hire).

React has a much higher share of the job market (at least in Australia and the United States). If you look on most job boards, the number of React jobs advertised relative to Vue is significant (nearly 8x as many React jobs at the time of writing this based on 10 seconds of job-board searches).

While React appears to win on this metric, I refuse to let React get points on the board, so I’ll make the following (water-tight, unassailable) argument.

There are opportunities for both React and Vue in the job market. Companies using Vue or React both find it difficult to hire, and, in my experience, there’s a skills shortage for both. As someone looking for work, you can achieve mastery (or perceived mastery) of Vue much faster than you can with React. This means you should get an accelerated path to higher salaries. You’ll also have less competition when interviewing as React is still the most popular choice for many developers who are currently victims of the sunk-cost fallacy.

As a company or hiring manager worried about competing for talent in the current market, Vue offers an opportunity to build more product per resource (carbon time benefits of Vue) and to grow your own talent (faster learning curve). Choosing Vue for greenfield projects or a new startup could just be the best decision you ever made when it comes to hiring.

As more companies realise the benefits of Vue, I believe it’ll continue to swallow market share — and may even overtake React as the framework of choice in the future.

Winner: Tie

Conclusion and Closing Remarks

This was a semi-tongue-in-cheek article about Vue and why I think it’s superior to React. I think React is a perfectly reasonable tool for building front ends, and I’m not claiming it’s bad. I just believe Vue has achieved a better balance in framework design.

I would choose React over Vue in the following scenarios:

  • You want to work somewhere that uses React — e.g., Facebook
  • You have a team of experienced React developers
  • It’s easier to hire for React in your area

I honestly don’t think there’s a single technical reason I’d choose React over Vue for the kind of applications I build or work on. This doesn’t mean one doesn’t exist, but I’ve just not come across one yet.

Svelte and Elm are both incredibly interesting options I’m following closely but am uncertain about their viability for large-scale enterprise applications at this point in time.

If you want to learn Vue, I highly recommend this free course by the amazing Jeffrey Way.