MVC vs Flux – which one is better?

MVC (client side) Flux
Born on 1976 Born just a few years ago
Bi directional data flow Uni directional data flow
Data binding is the key Events or actions are the main players
Controllers handles the business logic Store does all calculations
Somewhat synchronous Can be implemented as completely asynchronous
A trusted architecture used by a lot of companies in a lot of projects Recently created; but facebook claims it helped them to solve complex problems which MVC couldn’t

MVC is old trusted and Flux is new and promising. One served the world for a long time and the other is hot in current community. This article doesn’t speak in depth of these two as you can read their docs or guides from wiki or their official sites. Here we are trying to discuss the key points that are praised or created problems in developers life.

A little on MVC

MVC is an architecture first introduced by Trygve Reenskaug into Smalltalk-76. Since then it has been adopted by many developers group and companies both in server and client side development. Though many of them has modified the actual principal, some came up with MVVM and MV* kind of architectures, but the focus was on MVC and that’s why it’s one of the most successful architectures.

MVC splits the application in three different parts; model, view and controller where the view is used to display data and receiving the user input, the controller is there to handle the business logic keeping the model with it. To know in depth you can visit the wiki page.


Good point of MVC

Did a great separation of code. The separation of logical, representational and visual code makes it very easy to maintain. In some JS frameworks like Ember we can find a good implementation of MVC with a structured model class. As you can add remove or do anything with an object in JavaScript; having a strict model helps to restrict the team to introduce or remove properties by themselves.

Bad Point of MVC

MVC in server side is just awesome. But I think this architecture concept is so flexible that people implemented it in client side, moving away from the actual concept. Maximum JS frameworks provides data binding support which let the view to talk to the model directly, which shouldn’t be. Many times it become hard to debug something as there are scope for a property being changed by many ways.

Describing flux architecture

Facebook developers were facing problem scaling their MVC application and as a result of that the world got a new architecture flux. In a conference of FB developers, they showed how following MVC messed things up using the following diagram:

facebooks view of mvc

They also had given the example of their chat system development. Firstly they had a small chat window. Few months later they had to show the chat related info in the header. After few time they implemented a chat page and all of them needed to be in sync; like one manipulating the 2nd and 2nd doing the same to third and again third doing something with first. This created circular dependency and highly unmanageable and non scalable code. So they decided to change the fundamental architecture and came up with flux.

Flux is an action driven architecture where view can just display data and raise events or actions. Views receives their data from Store which is also capable of raising actions. Raised actions are handled by a central dispatcher which let the listeners to know that the action has been triggered and also provide the data sent by the initiator.


Good point of flux

All data change operations in flux has a common initiating point; i.e. Dispatcher. This is a huge advantage while debugging. We exactly can trace down what changed the value of a particular property, while in case of two way binding, things become unpredictable.

Bad point of flux

You always need to know about the actions which are already there. Actions are the main bridge of communication in this architecture and you can’t really duplicate them. This increases the headache to have a knowledge of already registered actions, which may become a pain I think.

Is flux better than MVC?

Though it’s too early to draw any conclusion on flux’s capability, when MVC is decades old. But there are few points we can judge, which has been mentioned below.

Is flux something out of the world?

Well, I personally didn’t find much difference between flux and MVC. Flux is more like a derived architecture from MVC. If we do some modification in the flux diagram, I think we can actually see what was modified.

flux is mvc

Is MVC really not scalable?

If we again have a look at the image which facebook showed, we will find there is a single controller with multiple models. This is not the way MVC principal speaks. In MVC, a controller has a single model.

facebooks view of mvc

So either FB developers messed things up with bad codes by themselves (without any blame to MVC), or it’s just a publicity stunt to make flux popular. Or there is a third angle too, which is, may be the facebook application needs its model that way. If we see the flux architecture, the store in something which just provides data. Not in any structured format or to any specific view. It just can provide data to multiple different views and may hold the combined model of multiple views.

So if we consider the third angle mentioned above as the reason, then flux really solved the purpose of facebook’s complex requirement.

Is Flux a bluff then?

Not really. MVC has problem talking to parallel elements. MVC is like a tree structure if we consider view as a leaf, controller a parent node of that which also has another parent controller and so on, it is really hard to communicate between two siblings until and unless you involve the common parent in the communication. Introducing parent requires to write more code in the code base.

So if in an application (may be component based applications works like that) communicating to parallel elements is necessary, event driven architecture is more suitable.

Should we prefer Flux over MVC?

I think the Flux is not another architecture, but MVC itself. Till date we failed to implement MVC properly in client side apps. Flux has shown us the right way to implement MVC. Renaming controller to dispatcher and creating store instead of models doesn’t make you a completely new architecture; but a BETTER structure. So yes, Flux is a better way than the existing MVC in client side.


I love React. It’s really awesome. But is the architecture flux as awesome as React? Flux has been extremely useful for facebook or applications similar to facebook. But how much will it be able to handle the other applications is something time will tell.

If the community is talking about flux today, then obviously it’s something promising. But there are a set of people who are rejecting it due to their love and ease towards two way data binding.

About This Author

Hello! I am Paul Shan, a JavaScript Expert, Full Stack and DevOps Engineer cum Consultant based out of Bengaluru, India.

  • Matthew Webb

    Nice article! It should however be checked for basic grammar and punctuation errors, “band point of flux” for example. 🙂

    • Paul Shan

      Yeah you are right.
      Thanks for notifying 😀