I used Angular 1.x a lot in the past, until I started using React. I use these two items a lot. However, there are several reasons why I switched to React. At first it wasn’t clear why, but looking back, I think I can make a pretty good summary.

Why did I migrate from Angular to React? I give 10 reasons. I used to love every aspect of Angular, but it’s time to remove it. This article will help people understand the benefits of React. It will also help people understand the benefits of Angular, and then let people choose between Angular or React, or even React and Angular 2.

This article is not intended to criticize Angular. Angular has been a great single-page application experience for me for a long time. I like this framework because it gives you everything you need. Since I’ve only used Angular 1.x extensively, I’m not going to talk about Angular 2 in this article, but I think the principles behind most frameworks are the same, and they apply to Angular 2 as well. Finally, I will only offer my personal experience with these two solutions. This article is not a comparison of the two solutions, but rather a reflection on why React was considered as a solution. There is no point in comparing apples with oranges. But it makes sense to reflect on why you can use or why you chose a particular tool. Let’s take a look at 10 reasons I like using React now.

React is just an image library

Single-page applications (SPAs) follow the common sense of component-based user interfaces. The component takes input and returns an instance of the component as output. For example, the output could be a simple button element. You only need to define the input and output and internal behavior for your component once, and then feel free to use it to create instances in any DOM hierarchy. In the best case, the components defined are easy to reuse and assemble into other components. React is ideal for component-based user interfaces. It is simply a visual library and addresses the requirements of all described components. It is a library dedicated to solving just one problem: providing all the tools for building a component-based user interface. You can see React as an integral part of SPA. Once you need to solve other problems, you need other building blocks. Does your application need routing? Take a look at routing solutions for React. Does your application need extensible state management? Take a look at the solutions for different state managers. Do you need to perform asynchronous requests? Look at solutions like FETCH, Axios, or SuperAgent.

But you can also build applications using React alone. It may not have the sophisticated routing and complex state management required by applications, but it is fine for small applications. The React Learning Path introduces React by building applications like this.

React itself is just a building block of an application that provides a component-based user interface solution. Like any other building block, it is replaceable. Based on the user interface, you can use another solution to build components that can still be combined with other building blocks.

Angular is different in this respect. It’s not a library, it’s a framework. It provides more than one building block. It’s a more rigid solution. The ReactJs ecosystem and all its building blocks taken together can also be considered a framework. But compared to AngularJs, the React building blocks are replaceable. Angular does everything for you. This may seem paradoxical, on the one hand it should be easy to learn because you’re using your own building blocks, but on the other hand it’s quite difficult to learn each one at the same time. React isn’t easy to learn a lot at once.

React is an innovative place

React is just the core of the ecosystem, and everything around it is made up of building blocks. You have the flexibility to choose building blocks to solve different problems. React, however, maintained a simple interchange style. Their simple style of exchange has allowed novel approaches to sprout. You can use Redux and MobX as examples of state management. Redux had strong momentum early on, when MobX was an advocate for a small community that could make those two solutions intertrade.

Even though interaction is the core building block of React. More recently, libraries like Inferno and Preact have begun to compete with React as alternatives. It doesn’t make sense to use these methods in Augular because Augular has its own solution.

React interchangeable building blocks make it possible to try new approaches. Each of its approaches leaves room for the community to adapt, which allows the React ecosystem to innovate.

JSX – a mix of HTML and JavaScript

React has a syntax called JSX for making components. JSX is a mix of HTML and JavaScript. In addition, people often use inline styles in elements, mixing in CSS. It may seem confusing at first, but it will eventually adapt. You can combine and manipulate the DOM using JavaScript, but it’s embedded in HTML. You can use built-in JavaScript functions such as Map and Filter to display multiple (filtered) DOM nodes. You can also use ternary operations to render conditionally. You can use full JavaScript functionality in HTML.

In the SPA solution, it is a novel approach to defining components through a mixture of HTML and JavaScript. This approach has been around for a long time in server-side rendering schemes such as JSP.

In contrast, Angular makes a clear distinction between logic and view. It can use built-in expressions in HTML, like ng-repeat (Angular 1.x) or ngFor (Angular 2). This is done in JSX using native JavaScript map().

The React API is simple

React is an image library. It only solves one problem and handles that problem well. So there will be fewer ways to learn and understand.

The React component uses lifecycle methods. In the React ES6 component class, you can use lifecycle methods to access the component lifecycle. You usually just write the render() lifecycle method, which renders the element as a new instance of the component. The rendered code block is run during component initialization and each component update. That’s enough. However, you can use multiple lifecycle methods to add advanced component behavior. For example, you can use constructor() to initialize stateful components and add class methods to manipulate state. The lifecycle method is run again to update the view each time the state changes.

There are only nine lifecycle methods for a component. Most of the time, you’ll only use half of them — even in mature React applications.

Then you also need to know the methods of two React ES6 class components: setState() and forceUpdate(). You don’t usually use the latter method, which is used to programmatically force an update of a component. However, setState() is typically used to update the component’s internal state, which is initialized in the constructor() lifetime function. Imagine that your list component has a list of items. Then you want to add or remove elements from the list. You can use setState() to update the list by saving the list in the component’s internal state this.state.

You can learn more about the React API in the React documentation.

Now you know all the basic component methods. React has other concepts, such as props and state, the children property, or different component declarations. You can take your time and learn them step by step.

React itself doesn’t have a steep learning curve. It’s just a view layer with a few methods to master. If you learn React first, I recommend learning React and nothing else. The React Way to Learn is just that, covering all the topics mentioned above that you need to learn and master React.

Lightweight components => best practices

React components are defined in two ways: es6-class components and stateless components in the form of functions. The latter are just functions that take parameter input and return an element in output — these are components, too, but they don’t need templates, just plain JavaScript functions defined. I can’t say that Angular is easier to define components.

function Button({ onClick, children }) {
    return (
        <button onClick={onClick} type="button ">
            {children}
        </button>
    );
}Copy the code

Using functional stateless components everywhere is a good practice, but only when component state and lifecycle methods are not required. This best practice allows you to define lightweight widgets without losing reuse, componentization, and functionality, and without side effects. Such best practices are already reflected in the boilerplate code above.

Unidirectional data flow

Unlike Angular 1.x, React has no two-way data binding. State management in Angular components ends up being messy. State is almost impossible to predict, and there is no good way to deal with it. Eliminating circular updates in Angular 1.x is difficult.

React uses one-way data flow rules. Components use setState() to explicitly update their internal state. It must get the state from the component’s state object (this.state), and then the component renders again with the updated state. The same thing happens with the input (props) of the component, if the input is updated, the component is updated through its lifetime method Render. Never modify the inputs or internal state of the component directly. The one-way data flow rule should be followed to make React state management more predictable.