An overview of the

React is a very good library. It was the first tool to revolutionize Web development and has influenced many of the tools that have followed. However, the React library has a number of drawbacks and is not a good choice for developing large enterprise applications. In this article, I will discuss some issues. The purpose of this article is not to blame React for its shortcomings, but to explain why Angular is a better choice for developing large enterprise applications than React.

React evolution and rise

React is a library developed by Facebook to meet Facebook’s internal needs, with the sole purpose of rendering content to the screen and connecting your data to the DOM in a clean way. And Facebook doesn’t just use React for its entire UI layer. Facebook uses React only as a view layer for the custom VERSION of PHP it is developing internally.

  • Due to the hype of Virtual DOM and React Native, many startups adopted React. Many startups want to reuse the same code base to develop Web and mobile applications because it is cost-effective for them.
  • During the initial phases of React, Google released Angular, which is a completely different framework from AngularJS. Many companies find it difficult to migrate from AngularJS to Angular. This helped React capture the market.
  • With so many major changes in the initial version of Angular, many startups, small to medium sized companies think React is the future and Angular is going to die soon (but the opposite is true).
  • As a result, React gained high momentum and user base.
  • In the current situation, many companies do not take the time to identify the right UI framework/library for their applications. They just fell for the overrated React hype.
  • Because of the high adoption rate, many developers are learning React.

Let’s clear the air

There may be many articles, such as “Angular vs React” or “Why React is better”. Most of these articles are just clickbait and don’t have enough data points. If you follow them, you probably have some opinions about Angular and React. Before we get to the actual topic, I’d like to clear up any misunderstanding.

Myth # 1: Angular has a steeper learning curve than React

Legend has it thatAngular has a high learning curve, React has a low one, and it takes time for developers to learn.

Angular V2 was released in September 2016. Since then, Angular has released a number of major changes through 2017. Angular released V5 in November 2017 with a number of fixes and improvements. Because so much has changed during that time, many developers/companies find Angular’s learning curve steep and React easier. So this legend was true before Angular V5.

Let’s check our current reality

If your JavaScript knowledge is good enough, it won’t take long to get started with create-React-app. But learning all the ins and outs of React takes a little longer because to develop React, you need to learn the props, States, Component lifecycle, and so on…… In Angular, you need to learn similar concepts such as modules, directives, pipes, component life cycles, and so on…… So there’s not much difference.

But to use React you need to learn the unconventional JSX, which will slow you down even if you’ve been practicing for a while. Not only that, React keeps introducing new things like React Suspense, React Hooks, etc. Angular, on the other hand, changes everything completely. The Angular CLI makes Angular development faster, but create-React-app is weak compared to the Angular CLI. Since V7, Angular has become more standardized and simplified with each new release.

However, when dealing with real life applications, you would never use React: Redux (or similar) for state management, Axios (or similar) for performing HTTP calls, Webpack (or similar) to bundle your code, some third parties for routing and styling, and the list goes on. If you want to switch to a different tool, you have to relearn.

Second myth: React is faster than Angular because of the Virtual DOM

React is faster than Angular because of the Virtual DOM is a misconception spread by the React team themselves. They later removed the quote from the React website. In the following article, it’s clear why Virtual DOM isn’t fast:

  • Blog. Bitsrc. IO/incremental…
  • Itnext. IO/misconcepti…
  • medium.com/@hayavuk/wh…
  • Objectpartners.com/2015/11/19/…

The problem of the React

Too much dependence

React is just a view layer, but to build a project, you need to implement routing, make some HTTP calls, you need to establish connections between Redux and React, Redux and routers, and so on. For each mechanism, you’ll have to install third-party libraries that may or may not work well with each other or React. In many cases, you’ll write extra code to make them work well together. Finally, you must ensure that all dependencies work well together by maintaining too many dependencies. For large applications, this is time-consuming and risky, having to replace libraries and rewrite code instead of focusing on our core product features.

By default, Angular provides most of the general functionality in its framework. All you need to do is import it and everything is fine. The Angular CLI will help you upgrade Angular dependencies smoothly.

Separation of concerns

React greatly popularized the concept of JSX — having HTML-like tags in JS code. JSX is now widely adopted, even in other libraries! Many React developers argue – “JSX is just a matter of coding practices, not a problem at all”. But the reality is that there are many other issues with JSX, such as:

  • A big problem here is that the potential for code duplication is very high. You can’t do this either: use inline styles:hover. :focus, :active, you cannot specify media queries, and the only way to override existing component styles is to use! important. It can be bad if used too often. As a result, you end up with some tedious workaround or some third-party library to manage styles.
  • Attempts to invoke methods from a component template often result in an inability to access themthisCauses you to bind them manually.
  • If you write a lot of conditional statements in your application, the JSX approach is bad. This way of writing loops would be a nightmare.
  • Linters (such as ESlint) and code analysis tools (such as SonarQube) are often insufficient to prevent the worst coding practices.

True responsiveness?

The idea of a reactive framework is that one component can respond to status updates from another component in the application without polling for updates.

There are only two popular ways to propagate state across an application in React. They are:

  • Parent-child hierarchy
  • Redux

There is no need to explain why navigating through parent-child hierarchies is a pain. Redux is a huge global key-value store that is better than parent-child hierarchies, but very limited. It is actually a glorified global object. Its performance is fine for flat data, but as soon as you have several layers of hierarchy, it starts to break down.

In a truly responsive application, the state of any component is generic, straightforward, and independent, and can be subscribed to by any other component. They save more memory, provide better performance, and are easier to develop and organize. Most importantly for developers, the state of any component can be easily updated from anywhere without much setup.

However, React can be truly responsive with RXJS. There are other solutions, but why isn’t React responsive out of the box?

Angular has been using modern responsive patterns with RXJS as part of its official documentation since 2015. Even the original AngularJS (since 2009) was much easier to use than modern React in a responsive mode out of the box.

React has no standard data layer

React has no standard data layer. If you use Redux, Redux follows the Flux architecture. Your application will have hundreds/thousands/millions of flux implementations, all of which perform slightly differently. In the case of Flux, how the data layer works is unclear. With multiple teams working on it, consistency is always a struggle. To be consistent, you need to work harder than Angular. When you add new developers to your team, they may have to struggle to understand the data flow. Angular doesn’t have this problem.

Other problems

  • The other worst part of React is that it doesn’t address component styles. It’s an eye gallery, for God’s sake! Why do I have to research and explore the thousands of different React add-ons that claim to have “solved” the style “problem” — what’s there to solve? ! Just write some damn styles!
  • React Hooks are making things worse. Now it’s too strict to even allow TypeScript to work. For any normal Angular operation that is effortless, you have to skip extra loops, come up with very strange tricks, and waste days looking for a solution. For example, you can’t extend components to TypeScript classes because they aren’t even classes anymore. A big step in evolution.
  • Time estimates are easy because implementing a feature requires no more than a developer estimate, leading to a small number of possible confusions, errors, or omissions. The few concepts that need to be understood make communication with project managers easier.

Angular’s advantages over React

Angular + Web components

The benefit of Angular + Web Components is that they communicate in the same way through properties and events. You can use binding syntax on Web components just like any other Angular component. This means that you can pass any complex data structure back and forth between the two. This allows Angular to manage state/data while Web components remain stateless/reusable.

Lazy loading and preloading

Angular is very easy to use if you want lazy loading or preloading in your application. With Angular, you don’t need to create mechanisms like you did with React; you just need to add simple configurations.

More to add

  1. Zero configuration, no need to care about any Webpack configuration.
  2. The official infrastructure library (cli, HTTP, Router, Animation, SSR, and E2E) is provided and compatible with upgrades.
  3. Built-in RxJS, from View operations to Http are all responsive, can be arbitrarily combined.
  4. A version upgrade automatically migrates to the new version with a single command and fixes any possible incompatibilities.

conclusion

When developing enterprise applications, consistency, extensibility, upgradability, and maintainability are of Paramount importance. React is bad because instead of helping developers write decoupled, easily extensible, and maintainable code, it couples components through its props and state-sharing mechanisms.

Writing React code is a matter of dealing with workarounds all day (see the “Code Clarity” section), trying to write code that actually makes sense, and eventually cracking it and producing a very unclear solution. When you read the solution again a few months later, it will be difficult to read the solution. You will work harder to release your project, it will be hard to maintain, have bugs, and require a lot of training to fix. React is hampered by its fragmented ecosystem and efforts to improve performance at the expense of code complexity. For large applications, there was too much risk of having to swap libraries and rewrite code instead of focusing on our core product features.

Angular is very standardized, the CLI eliminates a lot of boilerplate work you have to do, and the CLI provides a lot of security when creating components or upgrading dependencies. Angular is a better choice for standardizing and simplifying front-end development.

reference

  • medium.com/@jacobfries…
  • Michelestieven.medium.com/react-is-be…
  • www.stackchief.com/blog/Why%20…
  • Kelin2025.medium.com/why-ive-nev…
  • Medium.com/building-pr…
  • Medium.com/nerd-for-te…
  • Medium.com/eincode/why…
  • medium.com/@kuncevic/w…
  • Medium.com/madhash/why…
  • Javascript. Plainenglish. IO / 14 – the features…
  • Gsync.medium.com/5-reasons-t…
  • www.spotdraft.com/engineering…
  • Areknawo.com/why-i-dont-…
  • www.infoq.com/articles/mo…
  • Javascript. Plainenglish. IO/throw out – r…
  • Sredmond.medium.com/5-reasoins-…
  • Sredmond.medium.com/why-we-need…
  • Sredmond.medium.com/why-angular…
  • Levelup.gitconnected.com/react-and-i…
  • Medium.com/codex/part-…
  • Medium.com/codex/why-i…

This article is translated from medium.com/kanth.vall…