DEV Community

Discussion on: React Js Vs Angular Which is Better ?

peerreynders profile image
peerreynders • Edited on

First, I would like to know, if there are any reasons for to only pick one of those frameworks

  1. You don't get to choose if the application already exists.
  2. You don't get to choose if there already is a "shop standard".

Angular is considered a "batteries included" tool, so it already has solutions to all sorts of problems - most of which your particular application may not even benefit from but with all those "goodies" it can take a bit of time to become familiar with what is there—which first time around can slow you down—hopefully that initial investment will be amortized over the development of subsequent applications.

React on the other hand only really provides a "component runtime" that manages the DOM and component state. But there is a vast ecosystem of dependencies that can be used to assemble your client side application. So people typically start with some minimal set of dependencies to get going quickly which they may evolve with time as they become more familiar with other dependencies available in the ecosystem.

Lots of enterprises settle on Angular because they like the "one stop shop" - i.e. no need vet loads of independent dependencies and solution approaches; there was a period of time where ASP.NET and Angular went hand in hand. However even there React has made some inroads because a significant number of front end developers like authoring with JSX-based declarative UI components (not to be confused with declarative programming).

To a large extent React is used with the aim to create 'native-like' UIs and the option of going "React Native" seems to be popular even though it isn't universally exercised.

Now there are developers who don't like the React/JSX way of doing things but find Angular to be overly complex. Many of them land on Vue.

For example "I have this certain requirement, which cannot be done with this framework".

In most cases there isn't a show stopper like that (there are always exceptions). In many cases it really comes down to the preference and familiarity of the person making the decision - as long as they can make enough hires that are willing to go along for the journey. However any one choice has consequences.

Tim Kadlec: The Cost of Javascript Frameworks

  • Angular tends to lead to heavier bundles (not a problem for internal applications)
  • React tends to be more CPU (and therefore battery) hungry

A good choice of technology is not something you need to drop soon, just because something different is supposed to be "better" or more famous.

We are talking web development here, tools age rather quickly in this space. React was released in 2013 and Angular 2 in 2016 (AngularJS 2010). These tools are old enough to still be fundamentally rooted in the "desktop web".

Sure adjustments have been made to make the technologies more "mobile friendly" but certain constraints were set in their early design. Miško Hevery tried to introduce some new ideas into Angular in 2019 but they just didn't fit—so he had to start over with Qwik which is nothing like Angular.

  • Svelte reduces bundle size by using component compilation and reduces CPU consumption by using reactivity instead of a VDOM. Svelte aims to require less source code (The Return of 'Write Less, Do More' by Rich Harris | JSCAMP 2019) and some developers prefer the "superset of HTML" component authoring style.
  • Solid goes further by using "fine-grained reactivity" and eliminating runtime components. Being JSX-based it tends to appeal to developers already familiar with React.

One thing to note is that Angular, React, Vue, Svelte, and Solid are by design client-side rendering (CSR) solutions (Rendering on the Web).

In an effort to minimize the delay to First contentful paint (FCP) all these solutions have Server Side Rendering (SSR) adaptations—however these were designed after the fact so depending on the implementation, SSR may not significantly improve Time to interactive (TTI).

The chase to minimize TTI is fuelling the development of the next generation MPAs ("this is not your father's website") in order to optimize on hydration strategies:

curiousdev profile image

I am very thankful for your detailed and insightful response!
One of the reasons, why I am aware of Web Development and interested of it is, that I had to work with "projects" (implementation of components extending another product), which are basically using web technologies, but not traditional Web Development, like creating complete websites/applications for visitors or the company itself. This led me to have a closer look at Vue, which you mentioned, but I also tried React for other reasons.
Please let me add to my initial question, that I just wanted to know features etc., that would make you have to use a framework, because of specific requirements. But you answered this later well, thanks. The comparison of Angular and React helps a lot, too!
Also I agree a lot on the part regarding the choice of technologies, which describes, that you possibly have to use, what already is in use. This is something I have experienced. People learning development should be prepared for this, if they want to work and develop. It is not bad to start learning with something well known and being able to use the knowledge for other similar technologies in a project, if this should be the case.

Thread Thread
peerreynders profile image
peerreynders • Edited on

It is not bad to start learning with something well known and being able to use the knowledge for other similar technologies in a project.

In this context we are talking about frameworks which have very different opinions (even the React component runtime is an opinion) on how to abstract over the web which often leads to accusations of:

  • Angular being unnecessarily bloated.
  • React unnecessarily re-implementing existing browser capabilities (e.g. the synthetic event system; it's only going to get worse with React Server Components; if you don't need React native consider using Preact instead; e.g. Etsy).

The point I'm trying to make is that learning to use a framework doesn't create a sense of the constraints the web has to operate under (native apps have it much easier); thus to the untrained eye it's not always obvious which tradeoffs are being made by any particular framework. So learning one framework may make it easier to learn the next framework but "understanding what makes the web work" isn't a given. Having a framework-centric view of web development can lead to products that behave like this in the real world.

If web development (e.g. What is a web developer?, video) was organized as a trade with an apprenticeship it could introduce developers to the whole range of available rendering options:

  • How to use HTML/CSS to create a static page
  • How to use JavaScript to add interactivity
  • How to use a static site generator (SSG) to generate an entire site
  • How to structure a server rendered site with dynamic content
  • How to use CSR framework for richer interactivity
  • How to use SSR to improve the experience of CSR applications

With that kind of spectrum of experience it would be much clearer when it is appropriate to use what technology. Instead people seem to exist at either end of that list leading to The Great Divide.

While it is true that frameworks can make developer's lives easier and more productive it doesn't change that:

  • The web is the most hostile development platform in the world (especially for resource constrained devices).
  • The web isn't one environment but a wide spectrum of uncountable combinations of client device capabilities, network conditions and server platforms/technologies. And web-based solutions cover the whole spectrum from documents to applications.
Thread Thread
optimisedu profile image

Great post
Main point from this which I will expand on: Learn the fundamentals and write for your usecase.

So angular is batteries included as you said. It also employs two way data binding and when badly written can be an objective mess.

You need to understand their lingo to make apps which are nice and performant after the initial load time.

Social workers for a pwa come included. That can be great, with both frameworks you need to think small and work up with a plan.

Angular is pretty opinionated which can be nice, or can be a bit overwhelming.

That said jsx takes a bit of a paradigm shift to work with which many people prefer.

They are both very heavy platforms which I feel are overused. They have definite usecases but if your project is small don't add thosands of dependency files. It's not a case of is X or Y better. Aim to know when it is best to use X Y Z or just vanilla sprinklings.

My 0.02