React vs Angular vs Vue
Angular and React are the two big players that are widely used. And there is an upstart that has been getting a lot of traction recently - Vue.js. Which is better, React.JS, Vue.js or Angular? Is React or Vue.js killing Angular? Is React or Vue.js faster than AngularJS? Belitsoft has an expertise in all three: Angular, React and Vue.js. However today we use React more often than other tools and we are strengthening our React team. Simply because it saves money for our customers (look at how our senior React developer Denis V. explains it). We also found and put together the opinions from the most discussed cases where different software developers are trying to find the silver bullet - so you can make the most objective decision possible.
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 full-stack engineer at WalmartLabs e-commerce division. It is a small team of 3–5 full stack engineers, 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:
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 architecture mistakes on the first version.
Elizondo says that he researched 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 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 because of the upgrade.
- Solve the critical bugs first and the upgrade. Again, not easy because I didn’t have all the necessary experience on 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."