Is Model-View-Controller dead on the front end?
medium.freecodecamp.com
Is Model-View-Controller dead on the front end?
1–10 of 106 posts
Re: Is Model-View-Controller dead on the front end?
#2Isn't this akin to what has been called MVVM in WPF land, or Presentation Model pattern by Martin Fowler, both more than a decade ago?
You have Model, View, ViewModel, and whatever auxiliary libs those need.
Re: Is Model-View-Controller dead on the front end?
#3Isn't this akin to what has been called MVVM in WPF land, or Presentation Model pattern by Martin Fowler, both more than a decade ago? You have Model, View, ViewModel, and whatever auxiliary libs those need.
From a comment to the article:
"The unidirectional data flow approach that’s in the spotlight right now thanks to Facebook is actually pretty darn close to what “real” MVC (as in the design pattern introduced first in Smalltalk decades ago and not the “server-side” appropriation that frameworks like Ruby on Rails popularized) is."
Re: Is Model-View-Controller dead on the front end?
#4> As more and more developers start to see the advantages of components and unidirectional architectures, the focus will be on building better tools and libraries that go down that path.
"Unidirectional architecture" is a weird name for what is a fairly standard abstraction. Every front-end at the top level is:
f(my_entire_state, some_event) -> my_entire_state'
Front-end development has been plagued by unclear patterns w/ weird names (MVC, MVVM, MXYZ...) since forever; everytime the patterns are criticized you hear "you did not understand it"; and new names keep popping up. It seems the industry is stuck remixing reasoning around nouns, and is unable to step back and reason around data.
BONUS: Sprinkle some CSP to get elegant concurrency, throw away callback-hell. Sprinkle some React to get fast DOM manipulation, throw away Flux (heresy!) - it has way too many names to worry about (action creator, action, dispatcher, callbacks, stores, store events, views) and encourages some bad practices around use of stores.
My $ 0.02
Re: Is Model-View-Controller dead on the front end?
#5Agreed. MVC has always been sort of an awkward pattern for frontend web development. The fact that the DOM is extrinsic to the JS runtime can lead to a messy collaboration of MVC components. An input that makes an AJAX request on each keystroke and renders the results to a list (typeahead.js for example) is easy to implement but involves quite a bit of indirection with this paradigm.
That being said, I don't know how to feel about Angular 2's approach to components. Decorators are useful but can diminish the benefits of component based architecture when misused.
Re: Is Model-View-Controller dead on the front end?
#6I'm a bit confused by the way the article describes MVC as going from "server-side" to "front-end" :)
When I was growing up coding native UI apps, MVC was all about front-end. UI toolkits were traditionally MVC or M(V+C) going all the way back to SmallTalk, and "server-side" typically meant apps without "V" or a "V" that was so small and hardcoded in without separation...
Re: Is Model-View-Controller dead on the front end?
#7Isn't this akin to what has been called MVVM in WPF land, or Presentation Model pattern by Martin Fowler, both more than a decade ago? You have Model, View, ViewModel, and whatever auxiliary libs those need.
IMHO it's somewhat orthogonal. You can can use the MVVM pattern with unidirectional data flow, where it's always obvious how data flows from a model/service to a viewmodel to a view. And were views only trigger model/service updates and never directly manipulate the shown data.
You can also however use MVVM with kind of a spaghetti data flow or apply unidirectional data view without MVVM.
I personally like MVVM a lot, and it also fits very good to the latest UI frameworks (Angular2, Aurelia, etc.). I would also always try hard to achieve a purely unidirectional data flow. I however don't care about whether to use Flux, Redux or anything else for that. In fact traditional services (aka implementations of some interfaces) that encapsulate a specific set of state work very well for me.
Re: Is Model-View-Controller dead on the front end?
#8MVC was originally designed as a pattern for desktop UIs. It has a single controller and a single 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 pur sang and it comes from 1988. How is React+Redux any different from this?
I agree with the author that components are the true innovation of React, because it encourages reusable building blocks by default. 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.
This is awesome about React, but it has nothing to do with data flow architecture, which is what MVC is.
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.
But saying that Flux/Redux killed MVC is like saying Clojure killed Lisp.
Re: Is Model-View-Controller dead on the front end?
#9MVC was originally designed as a pattern for desktop UIs. It has a single controller and a single 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). Th…
If anyone cares, by the way, actually having a Controller has done wonders for our code at TalkJS. Our View is purely React components, all of which only deal with presentation logic and local interaction logic. The components query the store (Model) for data, like in any Flux/Redux setup and like MVC has encouraged for decades.
Then, user actions are handled in the Controller. In our case it's just a bag of functions. The Controller fetches and pushes data from/to the backend, and sends appropriate actions to the store. This allows us to keep all the backend data fetching/manipulation logic out of the View, which keeps the View clearly focused on the UI and the UX, and nothing else.
Our controller does not have read access to the store: any data the controller functions need to do their work is passed in from the view (which has the data anyway because it used it to query the store appropriately).
This works great, it's total unidirectional data flow, it's also pure classic MVC, and I haven't seen anyone describe it elsewhere. We came up with it 2 years ago when React was pretty new and I had little else than MVC to be inspired by.
If you have data molding code all over your views (and a little bit elsewhere too, for good measure), consider a controller.
Re: Is Model-View-Controller dead on the front end?
#10I have the feeling I am reading Vogue describing what should be the new trend this winter.