Post-MVC part 1: We need to talk about MVC

Intro

In this series of blog posts I want to take a look past traditional MVC for the front-end. There have been lots of developments in architectures that do not look like MVC at all such as Flux and Reactive Programming.

The goal of this series is to show you how these other architectures came into being, the problems they try to solve, and how they relate to each other. This series is not an exhaustive tutorial on these new architectures instead it seeks to provide you information on a more conceptual level.

We need to talk about MVC

For a long time MVC has been our golden goose. It became our GOTO pattern for creating user interfaces. It has been been so ubiquitous that for a long time if someone create a new framework for handling User Interfaces, you would automatically assume that it is an MVC  framework.

But 'The times they are a changin'. MVC for the front-end seems to be dying of in favor of something "else". This is the first part of a  series of blog post trying to figure out what this "else" is.

But first we must define what MVC is.


Where did MVC come from?

In the 1970's a very talented group of people where working at Xerox's legendary Palo Alto Research Center (PARC). The home of many revolutionary ideas for the Graphical User Interface. It is the place where Steve Jobs famously got some of the ideas for the Apple computer.

So in the 70's they had a programming language called Smalltalk. Smalltalk offered an development environment in which you could graphically debug and inspect your program. Which was at the time revolutionary.

It comes to no surprise to me this same bedrock gave birth to the invention of the Model View Controller architecture.

MVC: a definition

MVC stands for Model View Controller. Three concepts for structuring your code. The Model represents the 'state' of the application. The state of the application is rendered by the View. The Controller manipulates the Model which in turn updates the View. The View offers widgets such as text area's and radio buttons to trigger the actions in the Controller which manipulate the Model.

Image visually explains how Model View Controller relate to each other.
It is the delicate interplay of three components which make Graphical User interfaces come to life.

MVC and the Web

It didn't take long before the web also started using MVC as a pattern to structure applications. Many server side MVC frameworks started popping up such as:
The Model would represent an Entity which was stored in a Database. It would often simply directly map on a row in a particular database  table.

The Controller was often defined as the place where HTTP request entered the application and where HTTP Responses where returned.

The View was the 'template' which took some Models and rendered the desired page. A Controller would send the complete View back to the browser.

MVC as a term had however lost some of its meaning. The jump from a standalone desktop application to a client-server model muddled the definitions of each 'letter' a little.

Should a model be 'fat' and be responsible for retrieving itself from database? Or should a model be lean and simply be used as an Object and let some Repository handle filling the data? Aka should we use the ActiveRecord pattern or the Repository Pattern?

Should a controller contain view logic? Should a model contain view logic?

Every framework answers these questions differently. In this regard MVC means something different per framework. Also slight variations on MVC started popping up such as: Model View ViewModel (MVVM) and Model View Presenter (MVP) adding to the confusion.

MVC is ubiquitous but that does not mean everyone's definition of MVC is the same!

Web Applications

At one point the web moved from having only websites to also having web-applications.

A web application behaves more like classic desktop application, they can be games or serve a specific business needs. For example a web application could:
  1. Manage a power grid for a utility company.
  2. Manage inventory for a store.
  3. Provide an interface to buy and trade stocks.
  4. Manage git repositories for an IT company.
For a time we built web-applications with the same technology as we did our websites. They were server side applications that used  JavaScript to enhance the usability of our web-applications. As time passed we wanted to do more and more complex things with our User Interfaces. The JavaScript behind those applications soon became spaghetti code.

In those days we would often use jQuery. jQuery marries the DOM and JavaScript via CSS selectors. Changing the DOM's structure could break your JavaScript behavior. The result was a very brittle application.

We needed to step away from the traditional fat server thin client model. In which the browser was simply used as a rendering tool for the UI, with some JavaScript to enhanced the User Experience. To a model in which the browser took full charge on how the UI was rendered.

Soon we started rendering our applications using JavaScript MVC frameworks. Which is the topic of the next blog post in this series: MVC and JavaScript.