Post-MVC part 3: Post-MVC Age


Last week we learned that the various MVC frameworks all share a the same abstraction called the Component, and that the Component is a tiny MVC application wrapped in one construct. More and more frameworks are using Components all the way down, this week we learn how an application which only uses Components works.

I call this the Post-MVC Age. 

Post-MVC Age

If we built our entire front-end applications with Components instead of using MVC how would that work? In this post I want to show you how to do just that. We will also discover some of the weaknesses of the Component model regarding state.

Post-MVC part 2: MVC and JavaScript


Last week we discussed what MVC is and how it was used to render application and websites from the server. But our application's user interfaces became too ambitious and our code became spaghetti. This week we will discuss MVC and JavaScript, and the birth of the Component.

MVC and JavaScript

Taking full control of the UI meant things had to be programmed on the browser side. Meaning that things had to be programmed in JavaScript.

This gave rise to the era of the browser based MVC controller frameworks. Backbone was the early pioneer showing us that we could straighten our jQuery Spaghetti. Angular and Ember improved upon Backbone by giving us automatic bindings, when the model changed the views were automatically updated.

Backbone, Ember, Angular are all MVC frameworks, which took the tried and true architectural pattern, and allowed us to make great applications.

And for a while everything was good.

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


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.