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.
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
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.
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.
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.
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.
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.
What’s your opinion on Angular vs. React? Which one do you enjoy using more?
Shahid FoySeptember 21, 2020 at 7:33 am EDT
How do react teams deal with all the licenses for the different libs that need to be handled not every lib is under MIT license. Do you guys launch prod apps with these different libs and hope you don’t get in trouble? Speaking in context of the libs that come packaged with angular under MIT license.
Andrei BaltutaSeptember 21, 2020 at 10:37 am EDT
Picking a package means looking at the license as well.
There are times when you have to reject using a tool due to lack of compliance with your project, and that’s fine. It doesn’t mean that the tool is bad!
You never want to take any chances when it comes to licenses, since you put your work and your client at risk.
Most common packages are MIT, in fact, it’s the most common license on GitHub and NPM.
The libs that come packaged with Angular also conform to the same license (MIT), I believe all of them do, but I have yet to check the myriad of packages and sub-packages and dependencies. Most licenses are permissive and can be used inside applications without problems. The GPL, for instance, emphatically does not say “anyone who modifies the source code must release their modifications for free to the public”. GPL is one of the more misunderstood ones and answers to common questions about it have been answered over and over again
If you have doubts about what licenses are fit for use in your applications and projects, I’d suggest reading through them and compiling a shortlist of those you can accept as dependencies.