React vs. Angular - Architecture Comparison

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.

First Things FIrst - Framework vs. Library

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 Architecture

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.

• Actions (serve a role of Controllers in MVC). These are javascript functions that react to the interactions originating mainly from the JSX (view). At the end of its execution, the action typically dispatches (by calling setState()) a state (model) to which the JSX can bind later in the rendering lifecycle. Everything matches with the responsibilities of a Controller from MVC pattern except the fact that sometimes you know too much about the view. e.g., to process the entire form data in action (such as after submitting a form), you will need to get hold of the HTML form element and retrieve values from the fields in it. In an ideal MVC implementation, you should be receiving a plain JSON object containing values from all form fields. Another sad example is having to receive an event as an action argument when you need to do custom stuff such as prevent the default behavior of propagation. Such little things break the MVC pattern, and therefore the React becomes just an attempt for it.
• State (serves a role of Model in MVC) gets dispatched by the action (Controller), and JSX (View) binds to it. This part fits well within the MVC pattern.
• JSX (serves a role of View in MVC) binds to the state (Model) received from an action (Controller). Furthermore, it can invoke a controller per user interaction by explicitly calling it. Therefore, in React, View is aware of the Controller, which again follows the MVC pattern. If only the controller could know less about the view - that would avoid the circular dependencies in the architecture, but probably in another version or another life.
• Component, while it helps to modularize the overall React applications, also comes with an architectural smell: It forces you to put actions, state, and JSX (all three elements of the MVC pattern) together. Furthermore, these three elements always become tightly coupled with each other, making it impossible to develop or unit-test them separately (e.g., with traditional MVC, we would want to unit test Controllers separately). By the way, speaking of unit tests, the official React website does not even explain how to unit test the component - maybe that is because it's not so easy to achieve? Either way, the component comes with the described architectural anti-pattern, and unfortunately, there is no easy way out of it.

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 Architecture

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:

• Component (serves a role of ViewModel in MVVM) defines and exposes properties (Model) to which the template (View) can bind. It also defines functions that the template can invoke on user interaction. At the end of execution, these functions change property values and thus inform the template that it's necessary to re-render. This behavior is standard in terms of the MVVM pattern. The violation comes into the picture because the component - through the decorator - mentions the template name. That means the ViewModel is tightly coupled with one particular View and therefore the View is not substitutable. In typical MVVM, a single ViewModel can be used with multiple Views as long as all those Views can accept the same ViewModel. Speaking about ideal solutions, Angular had to put the responsibility of tying ViewModel with the View somewhere else and not with the ViewModel itself (although it's just a decorator, it's still statically applied to the Component class).
• Properties (serve a role of Model in MVVM) are defined on the component and become accessible to the template (View). When any of the properties change their value, the template detects it automatically and re-renders itself. Everything is well within the MVVM pattern.
• Template (serves a role of View in MVVM) binds to the component properties (Model dispatched by ViewModel), and therefore it is aware of the component instance. This awareness is healthy in terms of the MVVM pattern, while the problem is with component knowing about the template.

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.

Do you want to help your team progress with software architecture in the front-end development? Look into another interesting article - Advanced JavaScript Application Architecture, or consider taking one of my training courses around software architecture designed for groups.

About Author and Content