Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is Model-View-Controller dead on the front end?

medium.freecodecamp.com

Post reply on HN
Print view View original

11–20 of 106 posts

Re: Is Model-View-Controller dead on the front end?

#11

Post by Quarrelsome »

Its the same pattern. The whole point of MVC isn't the damn precise implementation its about separating out the concerns of the view, the services/data and a thing or some things that control and/or glue it all together.

The point is to not munge all these things into one monolithic horrible grim mess. As long as you are separating the concerns of showing something to a user, allowing them to control it and backing it all with potentially remote service who cares what the pattern is precisely called? Its still flavours of this original desire that we named MVC.

All these presenter/unidirectional patterns are _just_ the underlying desire of MVC and the only reason that people seem to talk about how "MVC isn't right" or "is dead" is because they've followed MVC like dogma instead of just a guideline of separating your presentation, control and service logic. I had exactly this debate back when everyone was talking about MVP as if it was some revolutionary new thing. Its not, its all the same thing and GOF was never supposed to be a template for software but a way of talking about specific ideas that architects could then riff on. They're chords, not one specific tune that you _must_ play in a very specific way.

Re: Is Model-View-Controller dead on the front end?

#13

Post by qznc »

skrebbel wrote: post #8

MVC 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…

> MVC was originally designed as a pattern for desktop UIs. It has a single controller and a single model

Not quite. Let me quote from "A cookbook for using the model-view controller user interface paradigm in Smalltalk-80" by Glenn E. Krasner and Stephen T. Pope, 1988, which according to Wikipedia defined the term MVC originally:

> In the scheme described above, views and controllers have exactly one model, but a model can have one or several views and controllers associated with it.

Re: Is Model-View-Controller dead on the front end?

#14

Post by Silhouette »

buovjaga wrote: post #3
hvidgaard wrote: post #2

Isn'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."

Exactly. If you ignore misappropriation of terminology like the server-side "MVC" frameworks that had very little to do with MVC, and you ignore modern buzzwords like "unidirectional data flow" for the old idea that interactions update the model and that leads to updated rendering, then front-end web development today is following a broadly similar path to what general GUI architectures and visualisation tools did about 10-20 years ago.

People have noticed that views and controllers tend to come in pairs, and experimented with how to set up the controllers to receive events without creating excessive coupling.

People have noticed that you often want some sort of intermediate state derived from your model to support your view rendering, instead of regenerating expensive data from the model itself each time you render.

People have noticed that rerendering everything can be a bottleneck and developed tools for identifying only the changed areas to render selectively.

Tune in next week for: Immutable data structures are relatively slow. Large-scale declarative rendering is relatively slow, even if you use diffs. Fine-grained publish/subscribe models are relatively fast, and flexible enough to cope with both computing derived state and triggering UI updates, but you need good tools and a clean design or the edge cases will overwhelm you. Small-scale declarative UI updates triggered by a fine-grained publish/subscribe model is a useful approach in a lot of cases. And everyone hates temporary/transient state in forms.

Re: Is Model-View-Controller dead on the front end?

#16

Post by jwdunne »

The whole "x is dead" is pretty common headline pattern. It's dramatic, extreme and often just an exaggeration.

I can guarantee that MVC is still used on the fronted as on the backend. People are still generating value from MVC apps.

Perhaps it's not held up as the holy grail, since the new holy grail is pronouncing it dead. Perhaps it is dying. Dead it is often not.

After building out some front-end MVC work, I can see the value in Flux architecture and React components. I'd have a hard time justifying a rewrite though. It's still very much alive there for me. That's also the case for many others.

Re: Is Model-View-Controller dead on the front end?

#17

Post by rimantas »

hcarvalhoalves wrote: post #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' In the end all you need are well defined state transitio…

If the only tool you have…

Re: Is Model-View-Controller dead on the front end?

#18

Post by skrebbel »

qznc wrote: post #13
skrebbel wrote: post #8

MVC 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…

> MVC was originally designed as a pattern for desktop UIs. It has a single controller and a single model Not quite. Let me quote from "A cookbook for using the model-view controller user interface paradigm in Smalltalk-80" by Glenn E. Krasner and Stephen T. Pope, 1988, which according to Wikipedia defined the term MVC originally: > In the scheme described above, views and controllers have exactly one model, but a mo…

Good point!

All that said, they mean that you should use separate controller-view pairs for entirely different pieces of the application. A nice example would be MS Word's document editor (1 view with 1 controller) and MS Word's Print Preview view (same model, but a separate view and a separate controller).

What I was getting at is that in backend-MVC (and backbonejs-MVC), you usually build a view, a controller and a model for each domain entity (i.e. for each database table). This is fundamentally different from what Krasner and Pope describe, and it probably won't work well for the kinds of dynamism and interactivity most single-page apps are single-page apps for. I believe this is the flavor of MVC the author is talking about.

In our case at TalkJS, we don't have anything like a print preview - essentially our entire application is a pretty unified piece of UI (much like MS Word's document editor which, while complex, is pretty much inseparable), so we have only one controller and one root view. I made the thinking mistake that most UIs only have one root view, and of course that's not true. So thanks for that.

Re: Is Model-View-Controller dead on the front end?

#19

Post by iotscale »

skrebbel wrote: post #9
skrebbel wrote: post #8

MVC 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 function…

Correct me if I'm wrong but I think what you have is described as an "action dispatcher" these days.

For what it's worth, I think, we can define the whole Flux architecture in somewhat-skewed MVC terms. Not trying to downplay the usefulness of Flux here but if I'm not all wrong, it would've helped many people if we kept at least some of the terms from MVC or MVVM.

Re: Is Model-View-Controller dead on the front end?

#20

Post by skrebbel »

iotscale wrote: post #19
skrebbel wrote: post #9

Earlier quoted context omitted.

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 function…

Correct me if I'm wrong but I think what you have is described as an "action dispatcher" these days. For what it's worth, I think, we can define the whole Flux architecture in somewhat-skewed MVC terms. Not trying to downplay the usefulness of Flux here but if I'm not all wrong, it would've helped many people if we kept at least some of the terms from MVC or MVVM.

Ah cool, thanks. Does the action dispatcher also interact with the backend? My understanding was that it just created little action objects and little more. Our controller is decidedly more heavy-weight. I'm not saying it's the best possible way to go but it's been working well for us so far :-)
Post reply on HN