There are many comparisons online between the two most popular front end frameworks - React and Angular. However, all those comparisons often focus on specific features of these instead of comparing their architectures; Therefore, they don't give a clear idea of what the implication is of using one over the other. I feel that there is a need to clarify the mechanics between React and Angular from the higher level so that the developer trying to make the decision will have a more fundamental understanding of the possible choices.
Before we go any further, I need to warn you that I will be providing strict architectural judgment points that may put one or both of the compared frameworks in the unfavorable light. I cannot do anything about that - architecture is rigor, and it follows specific rules. In the end, my explanations should help you make a sober choice - it's better if you know what you are going for in advance.
You probably already know that React is a library while Angular is a framework (I will explain this in the next paragraph). Therefore, to make the comparison fair and structurally correct, I will mainly focus on the features that they have in common, and I will build the architectural vision and statements on top of those features.
React is a library because it only handles a small portion of what the full-fledged framework (such as Angular) does. e.g., Angular comes with a built-in mechanism for dependency injection while in React you need to import additional libraries if you want to have a similar capability. On the contrary, Angular also dictates some architectural choices while in React you have more freedom. We will talk more about this when I depict the architectures of these frameworks, so bear with me.
React is an attempt of MVC architecture. I say attempt because it violates a couple of essential guidelines of the MVC structure, but more about that later. Let's first see the visual representation of the React's architecture. Note that, in the provided picture, the direction of arrows represents the dependency/awareness and not the data flow.
In React, everything is a component, and within the component, you can identify three classic members of the MVC pattern - Model, View, and Controller. Therefore, I can refer to the React architecture as "Modular MVC" because it modularizes MVC structure within components. In other words, each component is a boundary of the isolated MVC implementation. Let's dig deeper into the component architecture.
Analyzing it from the higher level, React stands quite close to the MVC pattern and creates an impression of the request/response lifecycle with every interaction originating from the view. Every request goes through action, results in the new state, and finally ends with the view binding to the received state; But is it natural to expect such behavior in front end applications? To me personally, it looks a bit awkward because I consider a screen being a state and not a data flow. React tries to shift this vision a bit and makes it feel like a web server. Indeed, in a regular web server (e.g., with ASP.NET MVC), receiving requests from View, dispatching a Model, and binding the View to it while rendering feels much more natural. On the contrary, in the client-side applications, seeing a request/response-like pipeline is strange at best, if not an anti-pattern. Furthermore, the popular Redux framework that's often used in combination with React takes the concept of the flow to the next level, which makes React even more less like a front end framework. Maybe that's why the learning curve of React (and Redux) is so steep and importantly, awkward to most of the engineers.
Therefore, my verdict for React is that it forces a quite unnatural application framework implementation over the front end and you should be careful when choosing it for your front end application development.
Angular is an attempt of MVVM architecture. It's often mistakenly thought that Angular implements MVC pattern, because in 1.x versions there used to be a Controller in Angular. Back then it implemented something more like MVC, indeed, which is not anymore the case starting with Angular 2 and later.
As you noticed, I said attempt again - that's because Angular violates some principles from the MVVM pattern. Before we get into the details, let's look at the visual representation of the Angular architecture (only parts corresponding to MVVM pattern).
In Angular, everything starts with a component. There is much more to that in the toolbox (such as services, filters, routing, dependency injection, and so on), but that is outside of the scope for this discussion. Here is the breakdown of the responsibilities of the various elements when it comes to implementing the MVVM pattern:
Higher level application architecture with Angular looks more natural for the front end applications because it focuses on state mutation (i.e., screen is a state - naturally) as opposed to forcing you to think in terms of the data flows. Therefore, my preference for the front end applications always stays with Angular. I wish it didn't have that little architectural inaccuracy in it (which, I need to say, is minor compared to what we have in React), but let's hope that someday Angular developers will notice and fix it.
That was it with the architectural comparison.
It must be strange reading about front end and the architecture in the same article since I have rarely seen this done (or at least done correctly). I hope that over time the front end engineering overall becomes more aware of the architecture and things will get better. I am quite satisfied with what we have in this field, and it will only improve down the road because I have already seen significant progress over the last couple of years.
Author of the above content is Tengiz Tutisani - owner and technical leader at tutisani.com.
If you agree with the provided thoughts and want to make it part of your team's culture, we can help.
We provide in-person, immersive technical workshop training courses around Software Architecture, Domain-Driven Design, and Extreme Programming topics. We also develop software solutions.