For years, my go-to frontend framework was React. I started using it professionally around 2015 and so it was a natural choice to use for my personal projects as well since I was already in the mindset.
Of course, I have also dabbled around with others since then, particularly with Vue, but they never really stuck. I always just ended up using React in the end for whatever project I wanted to pursue.
So why would I suddenly want to start using Angular when nothing else stuck?
Note: I know that some developers call React a library rather than a framework. That is probably more accurate, but I’m going to continue calling it a framework in this article because when I say “React”, I’m referring to the entire ecosystem rather than just React itself.
A New Job
Earlier this year, I started a new job. I was hired as a frontend developer, but the project called for using Angular rather than React. When I applied for the job, I figured it would give me a good opportunity to truly try out another framework and see how it works, looks and feels for me. What I discovered blew me away.
Now, I know Angular isn’t the most popular framework amongst developers and particularly not amongst frontend developers. I’m pretty sure that is because it forces you to think much more like a backend developer than frameworks like React or Vue.
It is a strongly opinionated, object-oriented framework and you have to think in terms of classes (not the CSS variety!), services, components and modules. React and Vue are much more flexible in terms of how you can compose your components and structure your code. Both have their pros and cons, but as a full-stack developer, I’ve found I rather like having to write object-oriented code.
Why Angular?
After having used Angular professionally for several months now, I have decided that React just can’t compare to Angular in a number of different ways. I’ll sum them up here in no particular order.
Services
I love services in Angular. They are the primary way data is handled and are simple, intuitive, easy to unit test and ideal for handling large amounts of data.
So how do they work in Angular? I won’t go into a huge amount of detail because that is beyond the scope of this article, but I will give a very quick overview. Essentially, they are injectable classes that are used to fetch and store data in the application.
Angular treats each one of them as a singleton and therefore the data stored in the class is persisted during entirety of the user’s session. To use them, you just inject them into your component classes by importing it as a variable in the constructor and then you have access to all public functions and variables, including the data they hold.
When comparing Angular services to the closest thing in the React world, you get a combination of the native Context API and a third-party global store such as Redux. The Context API allows you to avoid prop drilling, but has to be used with caution because every time a change happens, React re-renders all of the rendered components that use it. Data is only persisted as long as the component containing the provider is still mounted.
Redux and other stores are globally available throughout the application and data is persisted throughout the entire user session. Re-rendering isn’t as much of an issue here, but all of that comes at a cost: massive amounts of boilerplate code. Writing reducers and thunk actions in Redux is powerful, but tedious and painful, especially if you use TypeScript. Getting the types right can have you pulling your hair out in frustration.
Angular services solve all of those problems and are as easy to use as writing any other class in TypeScript. That’s it. That’s literally it. No boilerplating, no re-rendering problems. It just works.
…read the rest of the article →