Angular vs. React: Lessons Learned While Switching to React

Most of my work experience, by far, has been with Angular. Recently, I became curious about React and decided to take the plunge to see what its ecosystem has to offer. While learning about the most popular JavaScript library, the differences between React and Angular became clearer. Now, I’ve decided to switch to React for all of my front-end projects.

What you will read below are my opinions about Angular vs. React, as I have been working with both. I hope this analysis will help you to make your own decision.

Pentalog is reaching new horizons every day and is always on the lookout for skilled people who can bring their knowledge and add value to our community.

I quite enjoyed Angular – its dependencies and ecosystem: I even recommended Typescript and RxJS to many and found Angular’s Reactive Forms useful. I also really liked having a powerful way to declare data flows using RxJS and composing streams of data into features.

What attracted me to React? First, its popularity. I analyzed the number of installations and realized that React handily beats all of its competitors. Spurred on by the results of 2019’s State of JS and by several colleagues who really enjoy working with React, I was determined to find out more.

1. Initial Impact

Before diving into React’s well-written documentation, I had cursory knowledge about it. I knew the name of some lifecycle methods, and only had a broad idea of how it operates.

Most people will probably notice one main difference between React and Angular: React isn’t a framework; it’s a library. This has several implications. I realized that I no longer needed to just learn React, but also make a few decisions about which state management to use and which packages I would use to style my application. To put it bluntly: I had to build my own framework, which isn’t as bad as you might think, but I had to avoid abusing my new-found freedom.

Another difference that I encountered between React and Angular was JSX’s versus Angular’s template. JSX is syntactic sugar for `React.createElement()`. While it’s entirely possible to write React without using JSX, the result is extremely verbose.

2. Package Pondering

As previously mentioned, I was a bit overwhelmed by the wide variety of decisions I felt I needed to make until I started treating external packages with the same attitude as Webpack loaders or plugins: add them when needed and when they solve problems.

While the React ecosystem is large and very colorful in terms of what it offers, smart decisions should drive the development process. Picking the right tool/package for the job is important.

Since most packages in the React ecosystem don’t need to rely on anything other than React, they play relatively nicely together.

3. Likes and Dislikes

JSX ?

React uses JSX as opposed to Angular’s template + directives approach. JSX is really simple to learn and use, but there are some limitations. For example, I needed to write `className` instead of `class,` but after learning the simple rules of JSX, I found it quite nice and easy to add that extra bit of display logically – like adding a placeholder image.

Extendibility ?

In Angular, it’s impossible to write true higher-order components. You can get really close by using directives and templateRefs. Whereas in React, your toolbox is considerably larger, or easier to understand and use. Patterns like Higher-order components and render props, give easy and simple ways of combining functionality. Not to mention other ways of sharing logic, such as custom hooks.

I can communicate between components in a variety of ways, and even write something similar to Angular’s services using React’s powerful Context feature.

One thing that I enjoyed was the documentation. It’s written clearly and the examples are relevant. Since its scope is smaller, React can focus a bit more on advanced use cases unlike the Angular Documentation, which I found lacking in places, especially when dealing with more advanced use cases.

Prone to poor splitting ?

One thing I dislike is the wiry nature of components. I felt like I was splitting up a lot of things and was a bit prone to doing “prop hunting”. But after a few attempts, I started to figure out better ways of passing properties around, mainly by eschewing aggressive prop passing in favor of things like Redux and/or Context.

A good rule of thumb I found was a maximum depth of 3 (three) before you might want to start asking questions about your data flow.

Ecosystem ?

Another difference between Angular and React is the breadth of the ecosystem. In my experience using Angular, I found the ecosystem to be, at times, lackluster, but sufficiently in-depth for my needs.

React’s ecosystem, on the other hand, is far more complex, mostly because React itself is just a library. As a result, it’s a lot simpler and, by design and definition, closer to JavaScript.

I’d also like to highlight two packages that are really interesting and might be worth looking into: Linaria, a zero-runtime CSS-in-JS solution, and Immer, a tiny package that allows you to work with immutable state.

Immer is quickly picking up speed and usage, mainly due to its inclusion inside the very well developed Redux toolkit.

A high rate of change ?
I like to ask my React colleagues once a year which packages and workflows they’re using. And surprisingly (or not), every year, their answers change. Their tools evolve and change; their components look different, and the way they split their state varies.

A high rate of change ?
This is also a good thing; it means there’s a lot of room for improvement, and people are focused on getting the most out of their tools. I’m glad to see so much work being done on improving the developer experience and final result.

• What about hooks?

If you’ve kept up to date with React or are just learning it, you’ll quickly come across “hooks”. The closest thing to hooks in Angular is Decorators, but they’re not equivalent.

Hooks allow you to reuse stateful logic between components. For some, they come at the cost of a learning curve but offer an alternative to the class-based approach of writing components.

Be aware, though, that migrating to hooks comes with some caveats, especially when using the `useEffect` hook, something which is described as the ‘stale-closure.’

4. Which One is Better and Why?

I remain a firm believer in picking the right tool for the job. In this case, both can do pretty much the same thing with React having, in my opinion, a bit of a better developer experience.

Obviously, I can’t objectively sell one as being better than the other. I will say that if you are on the fence with React, it will probably make you a better JavaScript/TypeScript developer.

• No, but seriously React vs. Angular?

I’d love to give a polarizing response here, but unfortunately, it all boils down to what you and your team decide. Learn about each ecosystem and try a quick proof-of-concept to see which one sticks better with your team. I can vouch that it’s easy to work with both.

When dealing with a framework, any framework, you stop writing code in a specific language and focus more on writing framework-specific code. With this in mind, React has an edge in terms of flexibility.

5. Would I Recommend React as Part of a Tech Stack?

Wholeheartedly yes. The usage numbers alone show that I am not alone in this sentiment.

More than anything, I feel that React is popular because it’s closer to vanilla JavaScript than Angular or Vue. This means that there is less to learn about the library itself, but more to learn about better practices.

What’s your opinion on Angular vs. React? Which one do you enjoy using more?

Check out my thoughts about front-end JavaScript development.