And what about things like asynchronous call handling, general forms handling or app state handling in React and Angular?
You see, that is my problem with all these comparison articles: They only scratch the surface. And most of the times people don’t like to go deeper, because… well, it gets bad.
I started with Angular and switched to React only to find a “fast” rendering engine, which has nothing more. It’s only a rendering library after all.
Web App Features
You want a app state handling? Well look into Redux or any other Flux-built-framework. Oh, you want to make asynchronous calls? Well, there is react-promise, react-thunk, react-saga or MobX for that; Have fun reading through every documentation or articles of them and understanding them. But since you are developing on a hype-based-development-paradigm, you’ll choose redux-saga anyway.
Then you want to write an API request. Good, what do have to do in a redux-saga best practice way?
- Define actions for request, start, success and error of a request
- Define action creators for each of the actions above
- Handle state changes in a reducer for each action
- Wirte the call in a saga
- Bootstrap the saga
- Connect your component to redux store, if you already haven’t
- Connect your action creator to your component component
- And finally make the call
Wow. This, ladies and gentlemen is the ugly truth of React-Readux-Saga: Boilerplate par excellence. You’ll have to do this stuff for every single request.
Handling a web app with 20 to 30 requests (as you stated in Virtual DOM vs Natural DOM — which, by the way, is wrong, since Angular uses a Shadow DOM) doesn’t seem like fun anymore now.
At the end you’ll end up with boilerplate mess, that no new team member will understand, since he or she has to read first all documentations required to understand the React stack for a modern web app.
The true learning curve of react for modern web apps
React for modern web apps (React + Redux + Redux-Saga) has a very steep learning curve. React itself is pretty straight forward. But all the missing things that are not included in the library will take a lot of time to find and to learn them. And it’s shameful that a fancy hip article writer doesn’t have to mention that, because it turns those articles unfair. You cannot compare a full-featured framework to a rendering library, specially not without telling about the steps to take for the library in order to achieve the same things as the framework.
Also: The counter argument of your “React has a better performance than Angular” https://medium.freecodecamp.org/a-real-world-comparison-of-front-end-frameworks-with-benchmarks-2018-update-e5760fb4a962. TL;DR of it: it doesn’t. It was once that way, yes. But if you are talking about a real world app, this argument gets squashed by real world facts.