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.
Performance
Scalability
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
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
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.
Latest comments (9)
As both a React & Vue developer I've come to the same conclusion. I share your point of view and additionally believe a big factor in React's popularity in the job market is that it has the Facebook "seal of approval", which carries a weight for managers similar to presidential candidate endorsements in the US.
I would add that while React "moves fast to break things" on the bleeding edge, Vue has a much more stable, though somewhat smaller ecosystem.
Also, its naming conventions (eg for lifecycle hooks) are more straightforward and its model closer to web standards (for what it's worth)
For performance there are a few benchmarks around that show Vue 3 significantly faster. However I’m not a fan of those as mileage varies with use case.
From first principles we know that the VDOM is almost pure overhead and the performance is proportional to the number of nodes that have to be traversed in a diff. We can therefore know that a smaller VDOM will be faster than a larger one. By removing static nodes from the VDOM we shrink it’s size and make it more performance. Mileage will vary based on ratio of static/dynamic nodes.
I agree that most major react options are understood by experienced devs. It does get harder when people have different preferences on how to do things though. I’m a big fan of convention, it’s just preference.
React market is indeed about 10x bigger than Vue. I’m not convinced this makes it much easier to hire though as there’s still a massive shortage of react developers (as with all devs).
I’m also not convinced that those numbers will hold into the future. For me the absolute biggest downside of Vue has been lack of typescript support. With Vue ramping up in adoption and that issue fixed I think Vue will be around parity with React within 5 years.
overtake React? sorry maybe in your dream bro .. as React Devs and a huge fan of Vue .. React has more opportunities than Vue ..
Yeah I mentioned React has a larger job market at the moment.
Given Vue’s performance benefits, speed of development and ease of learning I suspect the gap will close every year.
React has been around much longer and Vue has only really taken off in the last 12 months.
Just my prediction that we’ll see Vue approach and possibly overtake React one day.
I understand you bro .. but your know React is everywhere .. Not specified in one environment. there is React Native, React VR, React Desktop and React Blessed,, Vue only on the web, also with NativeScript still not mature enough,, I admit that Vue performance faster than React.
Yes React is huge and not going anywhere due to it's mass adoption.
Winner React for me in all of this.
React is a great framework :)
Hi Michael, this is a cool article.