I always wondered why there are more job posts available requiring knowledge about React. I wondered why many companies don’t consider using Angular. I wondered why bootcamps include React as the front-end of choice to learn for their students. I wondered what React has to offer that Angular doesn’t. That’s why, after more than 3 years working with Angular, I decided to give React a try.
Actually…
…I had tried to learn React in the past. However, for some reason it didn’t click for me at the time. My brain understood better the Angular way. That’s why I decided to try to understand React for the second time.
If this happened to you, that is normal. Some become React, Angular, or Vue front-end developers because that is what made more sense for them. In my case, I had learned Angular first as it seemed more interesting to me at the time.
My journey with React starts with going over the tutorial on their website. Overall, it was easy to understand. In fact, I was thinking: How on earth could I not get the concepts the first time I tried to learn React?
Simple…
Because some of the general concepts used in Angular are used in React.
Back to the point.
I went through React’s tutorial in pretty much two or three days, including React’s documentation. I personally liked React’s tutorial recommendation with regards to not copying and pasting the code from their tutorial but instead typing the code while following the tutorial. It encourages better knowledge retention without you even realizing it.
By following React’s tutorial, you will learn topics such as:
- Passing data through props.
- Using states to store and pass data across different components.
- Understanding importance of setState to update state properties. Hence, re-rendering the component.
- Understanding how to bind event listeners with custom methods.
- Understanding function and controlled components.
- Top-down or unidirectional data flow.
- Pure vs Impure functions.
- Composition vs Inheritance.
If you want to dig deeper, React can do a better job of talking about all these topics and more. Check their site.
Although I tried to avoid comparing between the two frameworks…
Wait… Stop there. I meant between a framework and a library. If you didn’t know, React is a library, not a framework. Angular is a framework. This is one good reason why Angular apps are heavier than React apps.
Back to the story…
…it becomes challenging in the era of preferring one over the other, which apparently React has more popularity. Like everyone learning another framework (or library), I liked some things. I disliked other things.
I noticed data communication between components can turn nasty really quick, especially when a top-level component is supposed to control the state while child components should limit themselves to present the data. The first thing that came to my brain was this won’t be pretty if I have to share data across nested components. I understood why oftentimes I hear developers almost demanding the usage of an application state management library, such as Redux.
I’m still not sure how to feel about passing a function to a child component as a prop. Sure thing, there has to be cases when it becomes handy. However, I consider functions should stay in one component to prevent creating logic not easy to follow, such as defining the functionality at a top-level component but executing it in a low-level or child component.
I’m not a big fan of the usage of JSX syntax as I consider better to have a separation between the template and the business logic. However, it is not a deal breaker. In fact, it promotes staying in the same file during the development process instead of switching back and forth between the view and the component. As you practice more, you worry less about writing HTML in a JavaScript file.
I liked how React apps are lightweight in comparison to Angular. In Angular, there are situations where you end up creating unnecessary files, such as CSS or SASS files that never get used, because most of the time we end up using Angular’s CLI to generate components. Not sure if there is anything similar in React yet. Nevertheless, in the absence of the CLI, you become more aware of manually generating files you care about.
In React you become more aware of the usage of the keyword this, especially when you find the need of binding event listeners to a component. I can see how most new programmers can have many challenges learning that concept. In Angular, although you know you are using the keyword because this is necessary to use for manipulating data or triggering methods in a component, in my opinion you end up using this keyword without really understanding in depth how to use it because the framework makes it easy to use it. At least in the process of learning the Angular.
Another aspect React places emphasis on is the concept of immutability. They teach it right away, and they constantly remind you that objects’ state can’t be modified once they are created. I don’t remember seeing too much emphasis on immutability concepts while learning Angular. In fact, I feel this is often not respected by many Angular developers until they come across very specific situations where an object’s state needs to be preserved to prevent undesired behaviors in code.
React recommends you use composition instead of inheritance to reuse code between components. Angular has a similar concept but with a different verbiage, which is using presentational components. As you can infer, these components are used to display data, which generally come from parent components, and avoid as much as possible any business logic, promoting reusability of components.
In React, you are constantly in control of the rendering process. In order to display and update the view, you have to update the state using setState function. Otherwise, you can keep updating data and store it in variables and you’ll know the view won’t re-render.
In Angular, the rendering process is done for you. Therefore, there is a likelihood of you re-rendering components that don’t require this, decreasing the performance of the app. Angular provides different detection strategies to better manipulate the rendering process. However, Angular developers, including myself, become more aware of the rendering process whenever we encounter errors related to attempting to update the value of a property whenever the re-rendering kicked off by the framework process hasn’t finalized, forcing you to manually detect changes as a temporary solution.
In my opinion, React is a good candidate of choice to start smaller projects involving fewer teams as it allows for quick changes on the go without worrying too much about preserving code standards and infrastructure of the project. On the other side, if you are dealing with large projects, which oftentimes are split in multiple microservices, Angular might be your better bet as it is easier to preserve code standards across multiple teams developing microservices in parallel.
It seems I’m pointing out more dislikes about React than I should. In reality, I got more interested in the library and decided to create a simple website using React, Gatsby, and Bulma in a couple of days. By the way, if you know the fundamentals of React, learning Gatsby is a piece of cake. Feel free to check it out clearntext.com.
All in all, if you have a couple of years on your back as an Angular developer and you are interested in learning React, I strongly suggest you follow React’s documentation. Seriously. The concepts are relatively easy to understand once you avoid thinking in the Angular way as there are transferable concepts. Take advantage of the concepts offered by one library or by the other framework if you know both of them and make a better decision the next time you decide to start a project. It will make a big difference in the long run!
