Five Biggest Takeaways After Switching from Angular to React | Snapsheet

Five Biggest Takeaways After Switching from Angular to React

Author: Anva Kondakciu

For someone deciding whether to learn Angular or React first, most articles and videos will point to React due to its popularity, performance, and simple API.

My first experience with these frameworks was using Angular at an internship. At the time, I did research to see which tool was “better”. My biggest takeaways were:

Admittedly, most of the research I had done about Angular was true. Unlike un-opinionated tools like React, Angular has a specific way of modularizing and structuring its code. This involves dependency injection, reusable services, TypeScript, and more.

Starting with Angular meant learning the basic functionalities of an entire framework, unlike frontend tools like React, where the learning curve is focused on the view layer.

After two years of using Angular for personal projects and company deliverables, I became familiar with designing code compliant with Angular’s “opinions”.

Eventually, I was assigned to work on React projects. Moving from Angular to React meant knowing what skills (like thinking in component-based architecture) I could transfer to React, knowing what skills were strictly under the scope of Angular, and realizing React is not so simple your cat can master it in a week.

Understanding the Basics – What are Angular and React?

Many argue that React and Angular cannot be compared due to their differences.

Angular is a full-fledged framework, while React is a JavaScript library for UI development that can be an all-encompassing front-end tool through third-party libraries.

However, both tools have distinct advantages and provide powerful front-end solutions for similar use cases.

What is Angular?

What is React?

Takeaways

Now that we went over the basics, I wanted to break down my top 5 biggest takeaways after switching from Angular to React.

1. Learning Curve

When it comes to learning Angular, the term “learning curve” might be too generous. Being the powerful, all-encompassing framework that it is, Angular comes with a learning cliff.

From the Angular CLI to observables, templates, dependency injections, and dynamic rendering, Angular’s built-in features teach you the Angular-opinionated way to build speedy and scalable apps.

TypeScript was the cherry on top. It’s hard not to feel like TypeScript combined with Angular is a totally new programming language.

But what’s it like moving to React once you’ve internalized this pattern daily? It would be intuitive if I had to pick one word to describe React’s learning curve.

If you have experience with JavaScript ES6, React will come with a relatively quick learning curve. If you have experience with both JavaScript ES6 and a frontend framework with component-based architecture (like Angular), React’s learning curve is even quicker.

Being familiar with ES6 and component-based architecture, I didn’t need to spend too much time on it. State management tools like React-Redux and Redux’s architectural pattern took up a large part of my learning journey.

2. Third-Party Flexibility

When you’re working with a full-fledged framework like Angular, you may be familiar with using in-house tools to do most of your work.

On the other hand, React is a simple library based on JavaScript ES6. Because its library has such a simple API, it requires a handful of third-party modules to manage a large-scale application. While React easily integrates with third-party libraries, Angular is better suited for those that are specifically looking for a structured framework with built-in functionality.

3. State Management

Personally, I had never had the experience of using state management tools before learning React. One of the greatest learning curves I experienced in React was navigating and using the Redux store. Think of state management tools as a cache of data on which you can perform some CRUD operations.

Some Angular developers incorporate state management tools like NgRx in their applications. These tools follow a Redux-like pattern to provide a single source of truth for the app data with unidirectional data flow and exposed actions for accessing and making state changes. They’re also great for avoiding redundant API calls (if designed well). NgRx takes a lot of inspiration from the Redux library.

While there’s a decent chance that an Angular developer does not have experience with the NgRx framework or other state management tools, that same Angular developer transitioning to React (especially for an extensive application) will have a high chance of working with React-Redux. This isn’t as common in Angular because Angular is a complete framework that offers built-in tools to handle many of Redux’s use cases.

Redux Use Cases

Why is NgRx necessary for Angular?

Managing your data with services and subjects alone can become a complicated mess as your app scales. Additionally, opinions between team members on how the data is managed can clash. A state management tool like NgRx is beneficial for a team environment as everyone can understand the pattern to manage the state. NgRx-based applications follow a structured and unidirectional approach, maintaining a single source of truth for the application state.

4. Virtual DOM vs. Change Detection Tree

React uses a Virtual DOM (a logic tree that happens to be an exact copy of the real DOM), generating a new version of it on each state change and comparing the new version of the Virtual DOM with the old one. It then renders only the changes detected in the diff to the real DOM.

Because React sends updates to the DOM in batches rather than updating the DOM after each state change, performance is significantly increased.

Angular uses the real DOM, but does this mean that Angular is slower than React? Not exactly. While Angular doesn’t have its own virtual DOM, it does have a Change Detection Tree that helps the framework check whether the DOM needs to be updated with the new state. The DOM will only be updated if a model’s particular property has been changed.

5. Unidirectional Data Flow vs. Two-Way Binding

While React follows a one-way data flow, Angular allows for two-way data binding. With two-way data binding, changes to the data impact the view, and changes to the view trigger updates to the data.

I used to love two-way data binding for its flexibility of allowing write events to go back and forth between the controller and the view. In most cases, you have one piece of state in the controller and one piece of state in the view (ex: on a textbox). When one piece of the state changes, the other piece of state automatically updates to that same value. This can make debugging complex applications pretty time-consuming because it’s harder to isolate the bug when there’s no defined start point for the reaction chain.

After debugging with two-way data binding, working with one-way data binding felt like a breath of fresh air. The view always gets its data from the model, and you can only update the view by updating the model first. With React-Redux, you can dispatch actions to update the state. Because of the unidirectional data flow, it’s easier to detect changes and spot what caused the changes.

Conclusion

Now comes the age-old question. Which tool is better- React or Angular?

I’ll cut to the chase and answer that with:

“You must not declare any winner, because there is none! This is not a war, this is just one of the most fruitful times to build web applications, with lots of great tools out there.”

Having worked with both tools, I wholeheartedly agree with this quote. Every goal of a library or framework should be to make a developer’s life easier.

However, if you forced me to choose one to use for the rest of my life, I’d go with React (in a heartbeat). Here’s why.

Of course, everyone’s experience switching from Angular to React will not be the same. If you’re starting your React journey, I hope this article gave you a good breakdown of what to expect! 😊