Moving away from MVC

Sep 15, 2016
5 min read
Rapid7

Last updated at Mon, 06 Nov 2017 21:14:07 GMT

moving-away-from-mvc

In of all my years as a software engineer, trying new libraries, frameworks and paradigms has been such a pleasure especially in web development. Even before the well known javascript libraries, web development was based on backend apps which render heavy html code within css and some js code. Frameworks such as spring, .NET MVC, django and rails helped us with abstractions and predone tasks increasing development speed and quality (reuse principles). But, it was not enough. Apps were getting more and more complex with loads of user interactions and thanks to jquery we got some help with cross-browser deviations. This manner had been sustained for a few years, but evolution is necessary everywhere.

modelviewcontroller

But at the point , it was noticed that the lack of responsivity, performance at low resources and richer user interactions led us to reinvent the web development. The last 6 years brought us a sort of revolution which started from the most famous javascript frameworks such as knockoutjs, then, angular, ember, backbone and react. Those came with a mission to surpass old necessities.

Opening some parenthesis here, keep in mind that evolution usually works in a spiral shape. But for now… Let’s run.

dragonballz

New age, old manners

In the beginning of those six years, Knockout and Angular being born was our promise for better apps and more maintainable. Following the same concepts popped up Ember, which improved the rendering phase when compared to angular 1.X. The learning curve is not big whatsoever and the paradigms are the same. Now, we have UI components, DOM manipulation, filters, services, binding, so many things… Now our services are reusable, which means less code, doesn’t it?

Well, all of them fell into the same mistakes. The need of quick results made people push ahead once more the main problem faced by frontend development. It was never thought of as a new area, and therefore it had no new approaches. We needed to rethink/redesign our web development methodologies. Whereas backend has been evolved with REST APIs, NoSql and so on. Web apps no longer are only CRUD and frontend is not based on models anymore, but composed by them. Each view contains a lot of different models and even oddy temporary states. It is a fascinating world with loads of new challenges to face.

What’s the problem with traditional MVC for javascript ?

First, Javascript is not naturally an OOP language (Oriented Object Programming) – Accept it, so this will hurt less. Also, MVC is a design pattern that came up from the oriented object programming paradigm. Commonly, we have the same group of values (models) being referenced in different areas related to different controllers. Any update on these models should reflect different results and behaviours. Nonetheless, we have been forcing javascript be something different rather than take its full potential of not being it. Everybody knows about the banana-gorilla, isn’t it? If you don’t, check here. I am not against OOP. It is an amazing paradigm, but it has its own context of problems to solve.

Getting back to web (frontend), usually, our apps end up having a view attached to a controller that listen its events (triggered by user or not), delegates some actions and update the models. Then, the updated models are consumed and rendered into the view.

mvcwuser

I am not saying that is impossible using MVC on frontend these days, it is simply more difficult. Knowing that our views are everytime richer and more complex and, as mentioned before, we have some transient states for them that need to temporarily saved, our controllers oftenly are not maintainable and we lose quality in our project.

Evolution

So what to do then? Think, rethink, rest and give five minutes to new ideas. Facebook did it and came up with an alternative approach building up from the ground its own view framework, ReactJS. It is a good library to create components, one of most performant ones. But just creating a new framework is not enough. They knew that and brought us the Flux methodology.

fluxmethodology

Flux is an unidirectional application architecture for managing views (components). Its main concern is not about the model, but the state of the views.

The flowchart (fluxogram) shows us views, stories, dispatchers and actions. User interacts with views (components) that dispatch actions (small functions with single responsibility) which updates the stores and, finally, render the views. Although, It seems a bit awkward in the beginning, you make your app more predictable. Consequently, more maintainable and easy to test.

Would I make it easier for you if I said that is actually an improved MVC?

There is no app without data and in our state of the art they are REST APIs, so models still exists;
Actions and dispatcher consume, process data and update stores. Is this not a sort of controller?
View is just a representation of your state;

Ok! Flux is a decent approach to our problems, now we have states for views, we have small functions with single responsibility resulting in a more reliable app. However, Dan Abramov thought that architecture could be better and simpler. We still had multiple stores creating obstacles to notify different areas of the app. So, he built Redux.

Redux is basically an implementation of Flux consisting in one single store, read-only that gets changed only by functions (reducers). It broke the actions box into action messages and reducers. (http://redux.js.org/docs/basics/index.html)

That is a simple way of seeing it on MVC shape if you want (SAM – State, action, model):

sammodel