DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

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?

Danilo Castro user avatar by
Danilo Castro
·
Sep. 30, 16 · Opinion
Like (21)
Save
Tweet
Share
24.62K Views

Join the DZone community and get the full member experience.

Join For Free

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 behaviors. 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

The difference here that is unidirectional. But, if Flux/Redux is still scratching your brain, give it five minutes…

References

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/

Flux: https://facebook.github.io/react/blog/2014/05/06/flux.html

Redux: http://redux.js.org/

app Web Service

Published at DZone with permission of Danilo Castro. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Cloud Native London Meetup: 3 Pitfalls Everyone Should Avoid With Cloud Data
  • When AI Strengthens Good Old Chatbots: A Brief History of Conversational AI
  • How to Secure Your CI/CD Pipeline
  • RabbitMQ vs. Memphis.dev

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: