Has MVC died for the frontend?

In this article I want to share a translation of interesting reflections on the topic of the past and the present in the architecture of the frontend.

While more and more front-end developers are adopting approaches with a unidirectional architecture , the question arises - does classical MVC have a future? To understand how we came to this question, let's analyze a little the evolution of the frontend architecture.

Over the past 4 years I have seen many web projects and have spent a lot of time developing the frontend architecture and integrating various frameworks.

Until 2010, JavaScript (the programming language in which jQuery was written) was used mainly to manipulate the DOM and to tie in additional logic that animates the web applications. The developers were not particularly worried about the architecture, since things like the revealing module pattern did quite well with the task of structuring the code base.
')
Discussions on the architecture of the frontend in comparison with the backend actually began with the development of the concept of single page application (at the end of 2010) and with the growing popularity of frameworks like Backbone and Knockout .

Because then it was an innovation, the developers of these frameworks had to seek inspiration on the side, so they turned to already well-established practices applied on the server side. By that time, all popular server frameworks implemented the classic MVC (Model - View - Controller), also known as MV *, due to various variations in one form or another.

When React.js was first introduced as a rendering library , many began to make fun of it for intuitively obscure HTML manipulations in JavaScript. But the developers have missed the most important contribution that React brought to the world - component-oriented architecture . React did not invent the component approach, but took the idea to a new level.

This main breakthrough in architecture was visible even on Facebook, when they announced React as “V in MVC”.

Note: I still have nightmares after reviewing projects in which React and Angular 1.x were used at the same time .

The year 2015 was a turning point for developers' consciousness - from the familiar MVC, we moved to unidirectional architectures and data streams inherited from Flux and functional reactive programming using tools like Redux or RxJS .

When did MVC go wrong?

MVC is still, perhaps, the best way to develop server-side applications. Working with frameworks like Rails or Django is a pleasure.

The root of the problem is that the principles and decomposition that MVC represents on the server are not the same as on the client.

Communication controller representation

The diagram below shows how the controller and the view interact on the server. There are only two points of interaction between them, both of them cross the border between the server and the client.

When we transfer MVC to a client, problems begin. The controllers resemble what we call the “code-behind”. The controller is highly dependent on performance. In most framework implementations, it is even created by a view (as is the case with, for example, ng-controller in Angular).

In addition, if we recall the principle of sole responsibility, it is a direct violation of the rules. The client controller code deals with event handling and business logic to a certain extent.

Thick models

Recall what types of data you are storing in the model on the client side.

On the one hand, you have data of the type users and products representing the state of the application . On the other hand, you have to store the state of the interface — something like showTab or selectedValue .

Like the controller, the model violates the principle of sole responsibility, since you do not have separate ways to control the state of the application and the state of the interface.

So where is the place for components in this model?

Components are: view + event handling + interface state .

The diagram below shows how to actually split the standard MVC model to get the components. Above the line, there remains exactly what Flux is trying to solve: managing the state of the application and business logic .

Along with the popularity of React and the component-oriented architecture, we also saw the growing popularity of a unidirectional architecture for managing the state of the application.

One of the reasons for their successful joint use was the fact that the two of them fully cover the classic MVC approach. They also provide a much better division of responsibility when building a front-end architecture.

But this is no longer a story about one React. In Angular 2, you can see exactly the same approaches, albeit with different options for managing the state (for example, ngrx / store ).

MVC could not do anything better on the client. From the very beginning he was doomed to failure. We only needed time to see it. Through this five-year process, the front-end architecture has evolved into what we see today. And if you think about it, then five years is not so much to develop best practices.

MVC was needed at the very beginning, because our front-end applications became more and more difficult, and we did not know how to structure them. I think he coped with his mission and at the same time taught a good lesson about how to take good practice from one context (server) and apply it in another (client).

What does the future prepare for us?

I do not think that in the near future we will return to the classical MVC architecture for client applications.

As more developers begin to understand the benefits of components and unidirectional architectures, the focus will be on creating the best tools and libraries for this.

Will this type of architecture be the best solution in five years? It is possible that yes. But then again, nothing is certain.

Five years ago, no one could predict how we will develop our applications today. So I would not make any bets today.

From translator

I am a full-stack developer in the front-end department of Tutu.ru , 5 years experience. Previously wrote in C #, now I write in JavaScript / Node.js and PHP.

In Tutu.ru, the frontend has come a long way - from highlighting the train route when hovering (who doesn't know, Trains is our oldest project) to the full-featured SPA (single page application) in the new section Buses .

Until 2013, we did not have a front-end development department, although JavaScript, of course, was used. All the developers were full-stack masters, but they came from the backend. Therefore, it is quite logical that when the client code base became so complicated that it was necessary to structure it somehow, the developers tried to transfer the familiar and native MVC from the backend to the frontend.

It was better than nothing, but later we ran into problems well described in the article. In 2014, we gradually began to switch to unidirectional architectures and now MVC lives only on the back end (and in the Legacy frontend, as an honorary veteran).