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.
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.
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!
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:
- Manage a power grid for a utility company.
- Manage inventory for a store.
- Provide an interface to buy and trade stocks.
- Manage git repositories for an IT company.