Rate this article
Thanks for rating!

A kaleidoscope of frameworks and libraries which rule JavaScript trends by turns is not the news anymore. Developers from other fields even mock us, frontend developers.

I had to go through various libraries and  frameworks – qooxdoo, jQuery, Ext JS, Backbone .js, Ember.js, Angular, React in the process of my work.

The choice of this or that framework was not always voluntary. The outsource and outstaffing model imposes certain limits on my work. I think my colleagues will understand me.

The latest library which I have chosen is React from Facebook. I am not going to be secretive. I was not willing to switch to that library.  It meant leaving my comfort zone which is exactly what we do not like. The large number  of new words was scaring me, especially the “new” reinterpretation of architectural style by Flux and Redux and new terms – Actions, Store, Dispatcher etc.

You will agree that, given all the previous “hammers and nails”, the glossary was usually limited to something like Model-View-* (Controller || Presenter || Adapter || ViewModel || Whatever).

My understanding of that glossary looked exactly like it does in this picture:

The picture from the course “JavaScript Design Patterns” , of a rather popular MOOC-platform called Udacity.

I liked that picture. It made it easier to perceive the world populated with heaps of clones and various MVC interpretations.

There is the View – html, css and everything connected with them. There is the Model – JSON – the data and the place where we have taken them from. There is also the Kraken/ Octopus/ Wall-fern/ Multiarmed – which is some mythological creature  that unites the data and views.

MVO is the answer to all of the questions.

JavaScript Design Patterns: MVO


Suddenly Facebook comes and says (watch the video from 10:56):

“MVC is a bad thing, you can get stuck in it and never get out of this network of dependencies”.

Then it reports (watch the video from 19:36): there is a silver bullet – Flux and Unidirectional Dataflow.

It then presents the following information: Flux is complicated; Redux is exactly what you need.

You are inclined to believe it for this is Facebook and these guys are competent. However, you are gradually swimming with the stream.

Everything is now solved by means of this architectural style and library. Do you need to develop front-end? Ok, let’s take React, Redux and a little luggage like thunk, saga, storybook, themr, flow – and that does it.

Oh no, do not think that React is a bad library. It is actually wonderful. I am excited by Virtual DOM technology, because it solves a very important task. Its connection to the programming reactive paradigm also makes me happy. However, this “new” architectural style…

Our field is rapidly developing which is great. There are hundreds of times more programmers in 2017 than in 1980. That is also great. New cool instruments have appeared which simplify the life of an application programmer. However, at the same time, application programmers have started to think less. At least that is how it seems to me. I have written a lot of second-rate and complicated code during my five years of professional programming.

I decided to stop for a while and rethink web-application development as Facebook had done. I decided to find out why the Unidirectional Dataflow solves this cobweb problem, why nobody has done it before Facebook, and what is wrong with MVC and all of its arrows going in all different directions.

I started in the reverse order.


I started with having studied the definition that other top development companies have given to this architectural style. Most often we do exactly that: we watch how someone who is competent and carries weight does it.

Interpretation from Facebook.

However, we are familiar with it. Watch the video Hacker Way: Rethinking Web App Development at Facebook from 10:35.

Source: https://www.youtube.com/watch?list=PLb0IAmt7-GS188xDYE-u1ShQmFFGbrk0v&v=nYkdrAPrdcw

Interpretation from Microsoft.

Source: https://msdn.microsoft.com/en-us/library/

The Model and View are not connected invertedly, though it is clear from the description that the model responds to the status enquiry from the view anyway. In other words, the interpretation is the same as that of Facebook.

Interpretation from Apple

Those guys have two schemes: traditional and Cocoa API version.


Source: developer.apple.com/library

Hm, interesting. The first variant looks confusing. The model is connected with the view bilaterally, like in the previous interpretations. But the connection with the controller is not unilateral. The user’s action goes through the view and to the controller.

In the second variant, the model and the view are not directly connected. Interconnection is performed by means of the controller, and it resembles the picture with the octopus.

Interpretation from Google


The same kraken:

Below, there is a scheme from Martin Fowler’s blog.

Source: https://martinfowler.com/eaaCatalog/modelViewController.html

Martin Fowler has a very interesting series of articles about the GUI architectures, where he describes his interpretation of MVC in detail.

Interpretation of MVC from Java

Below is a MVC interpretation from a neighboring world, such as Java. It is not a coincidence that I am familiar with JSP. My so-called shady past:)

Aren’t you confused? Do you remember the series called X-files? The truth is out there.

One thing is clear – all of the variants are similar and they all tell us about the same, but there is no dogma in the interpretation of Model-View-Controller. Why is this so? Apparently, the initial definition was not very precise. Or was it?

We often judge technology by its appearance. We take into consideration someone else’s interpretation, instead of finding out the primary source and forming our own opinion.

What is the primary source of MVC?

The origins of MVC

It probably would have been worth while beginning the article with the same question that Uncle Bob asks at his seminar: Do you know who he is?

Trygve Reenskaug

This is Trygve Reenskaug, a professor at the University of Oslo. He is the creator of MVC and the first person to describe that architectural style. It was in 1978, during his visit to the Learning Research Group in the Xerox PARC that the foundation was laid for the basis of this concept for the project Dynabook, the analogue of the modern tablet.

The following quotation is attributed to him:

MVC was conceived as a general solution to the problem of users controlling a large and complex data set. The hardest part was to hit upon good names for the different architectural components” ( Wikipedia).

This statement is contrary to the vision of Facebook.

I wondered how the creator himself described that architectural style. Here are some interesting schemes from that epoch:

Source: http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html

Interesting pictures, aren’t they? The first thing that I like in them is the appearance of a new user. It seems to me that this is important for any scheme, which describes the architecture of client software.

The second interesting moment is that it is a connecting place for the controller and view in the early schemes. Trygve defines it as the Editor and later as the Tool.

He defined four terms in his first note on his concept: Model, View, Controller and Editor. The Editor is an ephemeral component, which the View creates on request as an interface between the view and input devices, like the mouse and keyboard.

After the professor had left the Xerox PARC, Jim Althoff and others developed and implemented the first version of MVC for the library of the Smalltalk-80 types. The professor was not involved in the development.

According to Trygve, Jim Althoff treated the term “Controller” in a slightly different way.

The essential aspect of the original MVC was that the Controller was responsible for the creation and coordination of its subordinate views.

In the later notes, the view takes and processes user input related to itself. The controller takes and processes entry data related to unit Controller/View in general, which is now called the Tool.

Martin Fowler calls this tandem Presentation Layer.

Trygve emphasizes in his paper that the basic actors of any client system are final user (Mental Model) and subject domain data (Domain Model/Data). The main aim of MVC is overcoming the gap between the user mental model and the digital model existing in the computer.

This concept is still relevant,  despite the fact that it was the SmallTalk epoch and there was no concept of web-applications. The essence of every program is the user and data interconnection. They communicate with each other by means of a layer which is situated between them.

Input and output threads are always the basis of the interconnection of a program and a human. A generalized scheme may look like this:

I, therefore, interpret the controller as a data input point, and the view as a data output point. Moreover, the input point is a complex of peripheral devices view control elements. At the same time, the view and the controller are slightly connected.  However, they do not communicate directly. The view delegates to the controller the obligation to send a message about the user’s action.

The input thread can change the condition of the subject model. The model  informs the user about its changes, using the data output point.

The connection of the controller and the view is presented as one-to-many in one of Trygve’s schemes. Why? I think it was because at that time, any button or arrow at the user interface was the view. Has anything changed since? I don’t think so.

The view is often interpreted as the whole page in the “kraken” interpretation. Actually, it is always a component tree. Each component can perform as easily as the view.

The connection of an interconnection layer with a user and a model is of the many-to-many type. It is also relevant for modern programs – one page may display data and features of various subject models. A model, in turn, may be represented by a data structure:

Let us try to formulate a generic description of MVC:

  • The Model (Model) presents the data and responses to the commands of the controller, changing its state.
  • The View is responsible for the display of model data to a user, reacting to the model changes.
  • The Controller interprets  user actions, informing the model about the necessity of changes.

We get Undirectional DataFlow:

Source: https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

Is it not the same as Facebook and Co suggest?

  • Store — data store.
  • Dispatcher — addresses the user’s action to the store.
  • View — a tree of React-components.
  • Action — user’s action, plain object.
  • Action Creator — initiates the action (object).
  • Reducer — change the state of the data store.

The revolution did not take place at the end. Nothing changed. Everything is performed by means of MVC as it was earlier. I observe only another interpretation of this concept and the substitution of definitions.

What problems were discussed by the Facebook representatives?

It is worth starting with the fact that over time the explanation of the concept about sharing responsibilities of the system has come to the realization of concrete patterns.

Look at the Apple schemes. They are describing system layers by means of concrete patterns: Observer, Strategy, and Composite. This mistake is continuing from the appearance of “Gang of four”.

The evolution of console software into server software influenced the primary definition.

Abstractions have turned into something concrete:

MVC Model 2

The problems were announced long ago. They will be same for Flux/Redux as well as for any other concept and framework. At first you have a clear thought and you start from something really simple. However, over time your clear code  turns into an ugly monster (kraken?). The project starts to get stuck in this software tar pit.


Will Redux and Flux help me to develop the architecture of my project more clearly? Will they keep my thoughts clear? Are there the instruments which will prevent me from getting into a mess with all of these arrows?

Being instruments and subsequent interpretations they are empowered to live. However, during this project I slowly started to cut Redux out. We shall see how things turn out. Will I manage to keep my thoughts clear or will everything turn into a swamp again?


The entire concept will based on the following, until essential changes take place in the field of Human and Computer interaction:

Everyone will pass this opinion. The problem of these hundreds of arrows will continue with this concept.

Just as someone can write clear code, but someone can get stuck into his swamp.

The aspects of this concept disappear within the source code of this swamp. I know it from experience, since many of my projects fell into mire.

Probably, you would like to ask a question: “OK, cool Bro, what then?”

Nothing, just treat this text as my own Brain Dump.

I am now glad that I have been plunged into these terms and this “rethinking” of the development of the web-application client layer. At least I have started to interpret MVC in a fresh new way. I started to explain these terms more abstractly.

I am also glad that I have become mature enough to publish my thoughts. Maybe, my opinion will change in the future and it will be interesting to come back to this text and laugh.

Artur Basak
Programmer, Lead Software Developer at *instinctools EE Labs

P. S. Everything that is written above is my modest subjective opinion and my interpretation. What interpretation do you have? I will be glad to see other opinions artur.basak@instinctools.ru

Share the article

Anna Vasilevskaya
Anna Vasilevskaya Account Executive

Get in touch

Drop us a line about your project at contact@instinctools.com or via the contact form below, and we will contact you soon.