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

51–60 of 106 posts

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

#51

Post by Swennemans »

skrebbel wrote: post #20
iotscale wrote: post #19

Earlier quoted context omitted.

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 :-)

It is indeed very close to how you would model redux apps. Interesting that you mention that your controllers don't have read access to store(s). That is actually very common with redux-thunk or redux-saga.

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

#52

Post by kgr »

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…

Very well said, but MVC is from 1978, not 1988.

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

#54

Post by lcarlson »

prance wrote: post #21
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…

I agree to almost every point, but note that in the MVC definition, each of the M, V and C are components, not classes. A component may be composed of several classes. So there's nothing inherently wrong with Rails' approach. I just think that as opposed to the original idea, people started to stuff way too much into their controllers, which is what makes things messy. I agree that Flux helps enforce the way it was s…

On the contrary, I find that people stuff too much on the model because of rails. I've found that I much prefer very simple models to describe very fine grained parts of the data and use the controller for much of the tying of things together. You kinda of treat models as 'data components' if you will, mixing and matching them where needed in the view

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

#55

Post by aikah »

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…

> trying to shoehorn DHH's backend remix of MVC into the frontend,

That's basically what Backbone was and yes it led to a fn disaster.

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

#56

Post by d0m »

amelius wrote: post #48
d0m wrote: post #47

I closely follow the Elm way (but in javascript with React), and it's still pretty much MVC. Model = the state, Controller = the update function changing the state based on action. View = declarative, need to send actions to change the state. Gets redraw on state change. Redux/flux are also similar. The idea of MVC, as far as I'm concerned, is to separate the View (Declarative as much as possible), the State (Just da…

But how do you update the view efficiently, and robustly (without introducing bugs or becoming less efficient as your view becomes more complicated)?

Well, this is exactly the goal of this pattern.

One thing I didn't mention is that I use MVC per component, not for the full application. (I use something else for the global Application level).

So, every major component has its own MVC. I.e. One page on mobile listing a items with a bunch of interaction would have its own MVC.

And why it's robust and efficient:

Very easy to reason about the data and write unit tests. The whole data is in the State, and only the controller can alter that state.

The view is completely decoupled because it can't change the state, it can only declaratively render something (we use React with immutable). And this is also very easy to test and mock with fake data.

As for performance, I've tried various strategies over the past few years, and I find Immutable data structure + virtual Dom pretty damn amazing. I personally use React.js + Immutable.js, mostly for the great documentation but this is definitely not the only libraries.

And if the view becomes that much more complex, then it's time to spawn a new component with its own MVC.

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

#57

Post by at-fates-hands »

blowski wrote: post #35
Quarrelsome wrote: post #11

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

I agree completely. If you model is echoing long bits of HTML, or your views contain lots of SQL, that's not really MVC. Almost everything is just details. We get excited about labelling them as 'ADR' or 'MVVM' but they are all just variations on a theme. Perhaps the problem is that rules like 'no SQL in your views' is now so ingrained, a lot of juniors have never seen a monolothic mess of SQL mixed with HTML. So MVC…

>> SQL mixed with HTML

And now we have Javascript being mixed with HTML; which I never thought would happen.

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

#58

Post by einrealist »

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…

Same for REST. Rails is one main reason why people think they use it, when they are actually not.

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

#59

Post by aplummer »

patates wrote: post #50
lojack wrote: post #41

Earlier quoted context omitted.

If you went with Backbone.js (or similar) you would have been better off than the standard bag of jQuery methods. Curious what you ended up going with back then? Most projects I start these days tend to use React. I've looked into Vue, and liked what I saw. I also maintain a 5 year old project built with Backbone.js (by someone else) and I'd say it checks all the boxes for maintainability, stability, and testability.…

Exactly! So many people assume that the emerging of a new "best" way of writing front-end software renders all previous architectural decisions wrong. It even came to the point that some people reject using any frameworks or even a helper like jQuery and "take everything under their control" because they don't want to deal with "deprecated" libraries. Meanwhile, a small development team I know keeps using Knockout.js…

Yeah, anyone who rejects jQuery in ie8 legacy rejects has screws loose, or a massive ego problem.

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

#60

Post by tambourine_man »

lojack wrote: post #41
tambourine_man wrote: post #36

It's in times like this that I'm glad I don't blindly follow the hype. According to the consensus, I should have gone with Backbone.js in 2011 (then Knockout, Ember, Meteor, Angular…) I'm still not completely convinced by React, and I may very well be wrong, but the same skepticism that sometimes makes me feel out of touch, also provides some sanity in this madness. For some reason that I can't quite point out yet, V…

If you went with Backbone.js (or similar) you would have been better off than the standard bag of jQuery methods. Curious what you ended up going with back then? Most projects I start these days tend to use React. I've looked into Vue, and liked what I saw. I also maintain a 5 year old project built with Backbone.js (by someone else) and I'd say it checks all the boxes for maintainability, stability, and testability.…

Still rocking jQuery whenever I can. It can grow into an unmaintainable mess, sure, but it doesn't have to.

First time I saw jQuery: Crazy easy and widely compatible, Ajax, selectors and animation - sold!

First time I saw React: Split your UI into components, write them in JavaScript (with optionally mixed in markup to make it more tolerable) - Hmm O…K….

Managing UI state can be complicated, but to me, not enough to justify the amount of complexity and abstraction added by React. If you organize your code so that only a single function can act on a specific block and emulate OO/namespaces in CSS, instead of attaching functionality to every click and overwriting stuff with !important, you'll be fine. It's not that hard, but maybe that's just me.

It's nice that the Virtual DOM is really fast (even thought I don't usually need that much speed) and that I can render it on the server (even though you can probably kiss your semantic markup good bye) and one way data binding seems a good idea, but again, I don't think it's a problem I have.

Post reply on HN