Is Model-View-Controller dead on the front end?
MVC was originally designed as a pattern for desktop UIs. It has a <i>single</i> controller and a <i>single</i> model, not the MVC style that Rails popularized with one controller class and one model class for every kind of data. In classic MVC, Views query the Model for relevant data. The Controller handles user actions and uses that to update the Model, then asks the View to redraw (preferably in some smart efficient manner). This is unidirectional data flow <i>pur sang</i> and it comes from 1988. How is React+Redux <i>any</i> different from this?<p>I agree with the author that components are the true innovation of React, because it encourages reusable building blocks <i>by default</i>. Contrast with classic desktop and mobile UI toolkits which, while often also using or encouraging MVC, do not require the developer to not subdivide their own codebase into reusable widgets. Instead, they allow composing an entire screen (window, page, form, whatever) from the built-in widgets. Making a reusable widget is possible but extra work and therefore not done. In React, it's the only way to go.<p>This is awesome about React, but it has <i>nothing</i> to do with data flow architecture, which is what MVC is.<p>The mistake webdevelopers made for years was trying to shoehorn DHH's backend remix of MVC into the frontend, throwing away decades of UI building architecture knowledge. I'm happy the Facebook people rediscovered MVC and I'm even happy they gave it a new name (Flux) because MVC frankly has gotten way too many definitions.<p>But saying that Flux/Redux killed MVC is like saying Clojure killed Lisp.