DEV Community

Cover image for Angular vs React
DigitalCrafting
DigitalCrafting

Posted on

Angular vs React

I'm not going to compare features of each, because it doesn't matter. You can write good applications in both. What I will compare is: how easy it is to maintain the project after the initial burst of code finds its way to master/main branch.

Let's cut to the chase: Angular is easier to maintain in the long run when you have people come and go to the project that lasts for a few years. It gives you everything you need (it's a framework after all) and it's well structured, even if you have to write a bit more code.

That being said, React is nicer to write in, and you could successfully write a large project in it, however, it is more demanding and requires great discipline to do so. It's just a library, you need to add to it to create something resembling a framework, and you need the strong will not to chase the new shiny solution, but to keep being consistent for the whole duration of the project.

Now, how did I get to that conclusion?

Projects

Angular

I've worked with Angular since version 2.0-RC in Banking industry. I wrote code for the Customer Service (in Bank branches, franchises, call center and some stand alone mini-apps). It was all in a single monorepo, it was basically one application consisting of many modules (Customer File Management, Transfers etc), all lazy-loaded, all configurable via admin panel. The modules were very Form heavy, but isolated from each other.

React

In React I've worked with deceptively small applications that had a lot of intersections between components and non-trivial business logic. I've used version 16-18 and Next.js. The most demanding was application for Airlines Call Center, which didn't have that much individual pages, but was very feature rich and the individual business components (ex: Tables and Forms for Flights and Services etc.) were reusable across the application.

Teams

In both environments I've worked in projects with teams consisting of 4 individual sub-teams, where the level of individual developer varied from junior to senior.

Why Angular wins on maintainability?

It's because people confuse React with a framework.

Let's get one thing straight - React is a library. When you visit React.dev, you see:

The library for web and native user interfaces

Whereas if you visit Angular.dev, you see:

The framework for building scalable web apps with confidence

And this makes ALL the difference.

Developers, even some of the senior FE developers, seem to think that React is all you need to write good application, and hooks (looking at you useEffect) are a god-sent. The React courses or tutorials are not helping by suggesting you should be calling API in the useEffect on state changes.

Tracking the cause-and-effect of React hook dependencies is a nightmare. It might work in small, short lived project like a portfolio website, but when we get more and more requirements and features in our application, it very quickly spirals out of control.

In order for React to work well for your project, you need to compose a set of libraries that work well together. You need to understand which patterns work in certain scenarios and which don't. You cannot just slap useEffect everywhere and hope for the best.

Little to no one cares about how many times the component re-evaluation is triggered, least of all the creators of libraries for React. One of the form libraries triggers the re-evaluation all the way from the root component at least 2 times, simply because the internal form state is defined as useState and is updated every time the input value changes. That's not acceptable.

Where React shines

React can be very nice for a team of seasoned developers, who understand that not everything needs to be written "the React way" - meaning hooks.

JSX is amazing for writing components. children prop is my favorite feature of the whole library, it was so refreshing to easily write wrapper components without having to worry about lifecycle.

With React you can easily shed all the dead weight slowing your application down but it comes at a cost of having to manually control pretty much your whole components life cycle, and most developers are not used to that.

Where Angular fall short

As pretty much every single article comparing the two states: Angular can be a bit harder to start with, mainly because of all the files you have to create, and all the life cycle methods you need to understand, but they are there for a reason. They work really well in a large, corporate projects.

Don't mistake standalone components for a full replacement of modules. Modules still are the go-to solution for structuring your code, especially in larger projects. Let's take a Money Transfer as an example, where you would have at least a few components, services and configurations, each for every type of Transfer (Own, Internal, External, Cross-Border etc.). You could take that module and lazy-load it as a coherent whole. Not only that, but you can assign modules to a specific teams, which would be responsible for their modules without conflicting with other teams.

Final Recommendation

For small applications, like a Portfolio, it doesn't matter, because the impact will be minimal, and you will likely be the only developer there.

For anything bigger, you should consider all the points above - will you choose Angular and have easier time maintaining it regardless of developers seniority? Or will you opt for React and deal with the future complexity yourself?

If you still opt for React, I have following suggestions:

  • Limit useEffect to a minimum. Prefer explicit calls on an event (such as click) to implicit call on state change,
  • Separate business logic from React components. Keep complex logic in services, so that React components are only responsible for rendering,
  • Keep the project consistent. - avoid new patterns or libraries in the middle of it, unless the business requirement demands it. Consistency matters.

Top comments (0)