To understand the above sentence you’ll have to read the whole article, and in fact you need to understand how most developers are working too. First of all, “most developers” are working for companies having software development as a secondary function. Some examples here are insurance companies, banks, hotels, hospitals, etc. These are companies who fundamentally don’t care about software, but need software to optimise their processes and fulfil their primary objectives.
These companies typically have large turn over, and the average employee rarely works at the same company for more than 2 years. This implies that once every 6 to 12 months, a new developer starts working for the company, and need to understand the existing code base to become productive. In addition, 80% of these company’s software projects are back office administration apps, not visible for customers. Examples are CRM systems, ERP systems, etc. With that in mind, let’s go through how React and Angular is typically used at these companies.
When you start out a new Angular project, the process is fairly straight forward. You make sure you’ve got the latest version of Angular, you install Material, and you start implementing your design. Each individual project therefor has a similar structure and largely uses the same components. This implies that every project becomes similar in structure, have similar components, and typically very similar markup and code – Assuming the Angular developer knows what he or she is doing. Maybe you’ll need a handful of custom components for your project, but in general if you’ve seen one Angular project, you’ve seen “all” Angular projects.
If you did the same exercise with React, you’d need to install dozens of components before you can even create a simple HTTP request and show a freakin’ date picker. Every single time you install a new component, you have a myriad of choices, resulting in that you’d rarely find two different React projects using the same set of components and plugins. The structure of the project is much more left up to you as an individual developer in regards to how you want your code and project to be organised.
The above differences implies that for the most parts you can replace any Angular developer with any other Angular developer, and after an investigation phase of maybe half a week, your replacement is equally productive as the person who worked on the codebase originally. This results in an “agile organisation”, able to easily move resources around between projects, without needing a longer learning period as resources are moved between projects.
With React the above is simply not true, because each React developer has his own favourite HTTP client, he’s got his own favourite widget library, he’s got his own favourite “whatever” library, resulting in that you’d rarely find two codebases with similarities at all.
So regardless of whether or not React is objectively “better” than Angular, it’s already lost at this point, since resource management at a “React company” becomes much more rigid, and you’re much more dependent upon individual resources, whom are more difficult to move around and replace if needed. You have created an unnecessary “dependency” from a business perspective, where you’re much more dependent upon individual contributors, and you’ve got less flexibility as a company.
In addition to the above, most Angular projects ends up looking similar. For a company having dozens of in-house developed back office administration applications, this is an advantage, since back office workers used to one app, can easily understand all apps. With React this is simply not the case.
So really, which of these two frontend libraries/frameworks are better technically, is at this point completely irrelevant. As long as Angular performs at least somewhat “close” to React, the technology behind, and its ability to perform, is no longer important for you as a company.
NOW you can comment and disagree with me … 😉
Edit – This is why we’re exclusively using Angular at Aista.