React vs Angular vs Vue
React vs Angular vs Vue: Popularity
The frameworks we are discussing are named the “Big Three” for a reason. They’ve got over 2 million downloads between them in 2018 alone. Though to be fair, most of those go to React.
The search trends tend to favor Angular and React over their younger competitor.
Google Trends Results
All three major frameworks are widely represented on GitHub, with React leading the pack.
GitHub projects as of February 18, 2019:
- React: 743,142 repository results;
- Angular: 468,411 repository results;
- Vue: 218,083 repository results
However, Vue was way ahead of the competitors by the number of new GitHub stars.
According to the StackOverflow survey, React and Angular are among the most popular 3 frameworks professional developers use. Vue failed to make the top-12.
The information is supported by the job postings. As of the time this article is released, Glassdoor search shows around 28.000 vacancies for Angular developers, 44.200 openings for React devs and only 61 for Vue coders worldwide.
In short, if you need frontend work done, finding Angular or React developers would be easier.
React vs Angular vs Vue: Performance
In terms of speed, the members of the Big Three are very close.
As they are technically similar, the actual speed of your project will depend on the skill of the developers.
React is the Best Tool for Cross-Platform Development
Denis V. , React developer at Belitsoft (3+ years of experience with React):
The official React blog states that the idea behind React is “Learn Once, Write Anywhere”. Actually, that is why I chose React.
React is the best option if a client requires both web and mobile applications. These are completely different types of applications, however, they can be developed by hiring just one development team instead of two. That significantly reduces the development time and cost. React is ideal for cross-platform development thanks to React Native or even for building VR apps using React-VR.
When comparing React to Angular and Vue, it’s important to remember that React is a library while the other two are frameworks. It means that React as a library offers the opportunity to choose what architecture and additional libraries to use, for example, Redux or Mobx, while frameworks force you to use a certain structure in your code make you use things the way this framework intends. Yes, with React you need to write a large amount of the boilerplate code to follow best practices for building highly scalable and reusable apps. However, there are many professional boilerplates for React, for example, this one.
Walmart Case Study: Migrating Angular apps to React
Ankur Tiwari is a lead engineer at WalmartLabs e-commerce division. It is a small team of 3–5 full stack developers, building and supporting an ecosystem of web apps that are primarily built on Node/Express/Angular 1.x stack. They use Webpack 2 as their task runner with code written in ES6 that gets transpiled into ES5 through Babel. The client side is an Angular SPA which talks to the Node layer. The Node layer integrates with Couchbase DB and other backend systems through REST APIs with JSON being the data exchange format. They have about 25 front-end reusable Angular custom directives shared across 3 web apps.
Ankur Tiwari noted that "Angular 1.x is pretty notorious in terms of performance when it comes to nested scopes and watchers. The problem becomes more prominent when you have custom directives built on top of open source directives. Imagine these directives composing a view that also involves multiple Ajax requests. That being said, Angular performance would have been pretty normal to me if I had not discovered the gains with React".
As an experiment, he decided to take the most complex view of the app and re-create it with React to understand the differences between Angular vs React performance.
Here’s what his Chrome JS Profiler said:
As they are technically similar, the actual speed of your project will depend on the skill of the developers.
Chrome JS Profiler results with Angular. Source: https://medium.com/walmartlabs/migrating-angular-1-x-apps-to-react-the-hybrid-way-3267ccf33755
Chrome JS Profiler results with React. Source: https://medium.com/walmartlabs/migrating-angular-1-x-apps-to-react-the-hybrid-way-3267ccf33755
As you can see above, there is a 35.5% reduction in scripting, 62.5% in rendering and 39% in Painting with an overall reduction of 1.5 seconds in view rendering!
Ankur Tiwari summarised why he chose React: "There were obvious technical reasons to try out React over anything else. It makes rendering/re-rendering of DOM nodes lightning fast. Not to mention its revolutionary concept of virtual DOM and only updating real DOM when needed through tree diff mechanism. Also, Electrode being WalmartLabs homegrown platform for web apps which is built on top of React and Hapi, it’s always better to have Electrode ready React components for any future web app to be written with it".
Rever Case Study: Migrating Angular 2 app to Vue.js
Luis Elizondo is the Director of Engineering at REVER SaaS Company that develops an Idea Management Software, named Rever Score. He does back-end and front-end Web development in this Silicon Valley-based company, founded in 2015 by people that blended their experiences in Toyota, Google, Airbus, Apple, Eurocopter, Rackspace, Procter & Gamble, and a handful of tech startups.
They are using Node.js / Express on the backend, vanilla Node.js with no framework for some microservices and Python for other microservices. Everything runs inside a Docker container.
In August 2017, Rever released a new version of their web client using Vue.js. Before that, they were using Angular 2 beta 9. Why did they use a beta technology in their products? It was a decision recommended and implemented by the outsourcing company, their line of thought was something along the lines “the final Angular version will be ready by the time we finish the product and we will update every time there’s a new beta release”, and they did, for a time, until they realized it was time-consuming and added no real value.
In the end, it took them 8 weeks to write the project with Vue.js. This was a medium size project from Elizondo's point of view. During that process, they were also rewriting the whole API because there were architectural mistakes on the first version.
Elizondo says that he has done extensive research before making a decision to switch their technology stack.
ReactJS vs AngularJS vs VueJS. Source: medium.com/reverdev/why-we-moved-from-angular-2-to-vue-js-and-why-we-didnt-choose-react-ef807d9f416
"Why we ditched Angular: I want to focus on tho points, the upgrade process and Typescript.
- Upgrade to Angular 2. This was not easy because there were many versions we needed to upgrade, doing this while having critical bugs was not an option since we didn’t know what things were broken because of the upgrade and what things were broken because they were already broken.
- Solve the critical bugs first and then upgrade. Again, not easy because I didn’t have all the necessary experience in Angular 2 and the documentation was upgraded. Try solving a bug that is happening on beta9 but you don’t know when it was solved or even reported with documentation that refers to Angular 2.0.0 and you’ll know what I mean. This is not Angular’s fault, this was just our context.
- Rewrite the whole thing and redesign the UI in the process. This is the road we took, it was the easiest solution for us, too many things were failing for us to attempt to fix them. We could had done it in Angular 2 as well, or we could experiment if we had other options. We did and I do not regret it.
Typescript is good, however, it was not adding real value for our medium size project. It avoids some kind of bugs, but not all, and we had a plenty, probably because the lack of experience from the outsourcing company. We wanted to avoid that as our team grows, there’s something beautiful in watching a new team member being productive after a few hours with Vuej.js, something we felt that we would not achieve with Typescript.
Vue.js solves the problems that we had, I’m not saying it will solve yours, and that’s why we moved, with our context, the business needs, the timing and the available resources that we had, I would make the same decision again because it solved our problems.
The reason why we ended up using Vue was coding speed, and a small learning curve, but those things pay off latter, when new developers come to the project they can start being productive in a matter of hours, not days.
Why we’re not using Angular 4 is because it didn’t exist when we made the decision to move to Vue.js".
This article accepted some critics in the comments section.
"I feel like we are missing some very important points here. We are comparing a framework (again) with a view library. Not only that, but you are also comparing the speed of prototyping between the two. I could tell you that based on that comparison, you would choose Vue without writing a single line of code. A framework is meant to give you a speed boost at the start of your new product and give consistency later on. However, when developing any kind of SaaS what you really care about is how hard is to maintain such software, as in speed on fixing bugs, implement new features, refactor.
React comes with just the view layer, and you are “forced” to take decisions by yourself. I’m surprised people keep listing this as a downside: it is probably the most valuable thing React delivers: freedom of choice. Feel like React setup is complex? Cool, grab one of the many available boilerplates and use one of those, Vue is just doing the same for you. While I like the overall article, I think the author failed on checking the long-term gains of one lib over the other. The more you grow, the less you want a framework, the more you want freedom of choice. And a bigger community. That being said, this article does one thing really well: scared me a lot regarding Angular2 (or 4 for what is worth), confirming my feeling that it’s a framework that came with a lot of issues (I come from Angular1 1 background)".
"My team and I use Angular since August 2016, we waited until there was a stable release before even looking at it.
We also compared Vue, React, Angular and even AngularJS (the first version of Angular). Took into account what we needed from the frameworks/libraries and the project itself, the scale and intended lifespan.
For us, Angular was the clear winner as it provides what we needed, but this doesn’t mean we will use Angular for every project. We look at it from the scope and requirements perspective.
Learning the syntax of a specific template or language is a breeze for any developer worth his/her paycheck and for me and my team has never been a reason to do or not do something.
Good that you did the research to figure out what was best for you, the team and the project, but if I can say one thing that I hope you’ll keep in mind; Never choose a framework or library because it’s familiar or easier. Choose what best fits the requirement of the project at hand."
"I have worked with the three last year (Angular, Vue, React, in that order), and although my preference goes as well for Vue.js. I’d like to clarify some things from an objective way:
- People that come from Angular (especially 1.x) find easier to get into Vue.js, since it shares most of DSL. What takes a while is to learn new practices and patterns of Component architecture. Once you know them, it’s really easy to get into both Vue or React. Of course, Angular 2+ takes much more. Personally, the easiest for me was React due to knowing already all the stuff, just needed to go to another syntax, and JSX is literally JS and HTML.
- Vuex or Redux… they’re almost the same. I agree Vuex seems easier, especially because it doesn’t need to be immutable (what it’s less clean in the other hand), but they’re almost the same thing with different names.
- What is true, lot’s of things are easier in Vue, for example, lazy loading + code splitting, and the DSL itself. Although, React makes composition easier since it’s just JS with almost no framework context.
I’m not making an opposite statement, just making clear there is no silver bullet. They all offer mostly the same, and what some find easy/better with one, other with the other. Best thing is always to analyze and choose what’s best for the project/team."
Codeship case study: migrating from Angular 1 to Vue.js
Roman Kuba is the Lead Frontend Developer at Codeship (now a subsidiary of Cloudbees), that provides a continuous integration (CI) platform. Their services are used by market leaders like CNN, Red Bull, Whole Foods and others.
With jQuery and CoffeeScript as their frontend stack, they managed to create a powerful platform. However, with the passage of time, the team felt the need in a more modern solution that will allow adding more complex functionalities and increase scalability.
The company made a decision to switch to Angular 1 at first, but after six months in use, it became evident that the framework would not satisfy them in the long term. There were two primary concerns with Angular:
The amount of data Codeship needed to deliver to their users far exceeded what Angular could handle. As a result, customers complained about page responsiveness, freezes and browser crashes. The team tried multiple ways to optimize the framework’s capabilities.
At some point, Angular was trying to grasp what was going on the page as Angular tried to keep track of its scope and ran the relevant digest cycles... That killed performance, regardless of whatever we tried to assuage the hit. There was no way it could have run smoothly”, Roman said.
2. Difficulties in performing unit tests.
“With Angular, we still leveraged acceptance tests as much as possible. We basically ran user stories in the entire application. It was incredibly painful to run unit tests with Angular itself and test component, module or controller only. It was barely giving us the full picture we so badly needed,” Roman explains.
To convince the staff and VPE (who heard nothing about Vue, but knew about Angular 2 and React, backed by Google and Facebook) to switch to Vue.js, Roman made practical research. He was pleasantly surprised with how smooth the codework was.
“In one evening or so, I rebuilt a crucial part of our rendering with Vue, and tried it against a large amount of Loglines as a proof of concept. Then I did all the CPU profiling. That was the one thing that immediately demonstrated to my team that Vue.js has already given us a huge performance improvement. We cut the rendering time from 30 seconds to 7 or so”, Roman recalls.
After a week he spent on refactoring and rewriting the page, the customers noted not a single crash “even with 15Mb of log rendered”.
As a result, Vue.js helped Codeship to organize their code, decrease time needed to add new features and improve UX.
“One of our pages that was running on jQuery had this weird kind of structure. We moved it to Vue and rebuilt it. Now, it provides a more granular experience and interaction with the UI, and so it significantly improved the UX.
With Vue, you’re able to harness the power of its components and start leveraging its ecosystem, like Vuex for example.
What we do right now is page state management—something we have never done before, not in such a clean way.”
On the testing side, Vue enabled moving away from acceptance tests to unit tests.
“I can run 15 tests that try to perform specific actions. Such an approach allows me to easily identify code breaks. This is not something I could do this way in an acceptance test due to the sheer amount of time it would take to run. And the result is simply not worth the effort. Unit tests are great in that respect. Code-wise I know that it’s bulletproof, as we test it in a completely new way and it’s incredible,” Roman says.
Articles you might be interested in: