Moving Away From MVC
Moving Away From MVC
Despite being around forever MVC still seems to have proven a popular choice in modern JS frameworks. But is it time to move away?
Join the DZone community and get the full member experience.Join For Free
Opening some parenthesis here, keep in mind that evolution usually works in a spiral shape. But for now… Let’s run.
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.
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.
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.
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.
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):
The difference here that is unidirectional. But, if Flux/Redux is still scratching your brain, give it five minutes…
Top ten reasons why web developers should use AngularJS: https://dzone.com/articles/top-10-reasons-why-web-developers-should-use-angul
How web design has changed over the last 10 years: http://inspiredm.com/how-web-design-has-changed-over-the-last-10-years/
Dilema banana-gorilla: http://www.johndcook.com/blog/2011/07/19/you-wanted-banana/
Give it five minutes: https://signalvnoise.com/posts/3124-give-it-five-minutes
Why I no longer use MVC frameworks: http://www.ebpml.org/blog15/2015/12/why-i-no-longer-use-mvc-frameworks-part-2/
Published at DZone with permission of Danilo Castro . See the original article here.
Opinions expressed by DZone contributors are their own.