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

101–106 of 106 posts

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

#101

Post by Silhouette »

lmeyerov wrote: post #93
Silhouette wrote: post #90

Earlier quoted context omitted.

In my experience, it depends very much on what you're doing. If a UI has light to moderate rendering requirements, React's approach might be fast enough on its own. In that case, a lot of the other ideas are just extra complexity for no real benefit. I'm speculating here, but I'd guess this actually accounts for a large majority of the web front-end work that is being done today. I haven't found that React alone scal…

FWIW, it's worth considering we (graphistry) work at the edge of what is possible in browsers. We hook up GPUs in the client to GPUs in the cloud for an unprecedently rich visual analytics experience. Think building Netflix, Photoshop, or Google maps for data. If mostly react and falcor, with only sprinkling finegrained rx, is how we handled the perf and composition mess, I'm pretty sure simpler apps can do even less…

Looks interesting... You're doing statistical visualisations using WebGL and GPU acceleration? If that's right, would you mind sharing a little of how you're setting up your overall architecture?

The web projects I'm working on are in a slightly different field. We also seem to be pushing the practical limits of browser-hosted GUIs with some of our interactive visualisations, but they tend to use SVG. WebGL is one of the technologies that is definitely on my "could be interesting/useful" radar, but I haven't tried to do anything serious with it yet, so I'm wondering how different a real-world-scale project would be.

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

#102

Post by amelius »

joncrocks wrote: post #79
amelius wrote: post #70

Earlier quoted context omitted.

I don't think that works well if the view is a complex function of the state. You can break the MVC into smaller components with an inner state, but how do you know which components to update when the outer state is updated? I believe you can't know, unless you duplicate the complexity of the smaller components into your larger component.

From what I understand, react + redux has a couple of tricks up it's sleeve. As the components don't hold state, only display the state of the model (part of the redux store state), components only need to be re-rendered if the state has changed. If you combine this with reselect ( https://github.com/reactjs/reselect ), then this allows you to only re-render components when the sub-set of the state tree is changed th…

Does that also work if the dependence on the state tree is not hierarchical? I.e., subcomponents referencing the state in a random-access way?

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

#103

Post by lcarlson »

mpweiher wrote: post #85
lcarlson wrote: post #54

Earlier quoted context omitted.

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

That's the "Massive ViewController" anti-pattern (or just massive controller, if you're not in Apple land). Classic MVC is really MVc, with controllers only handling a small set of interactions that are not directly between the Model and View, for example dialog boxes and such. One problem with a "Big-C" approach to MVC is that whereas models and views are at least potentially reusable, the controllers are dependent…

Hmm, often times the models are not reusable because they end up doing too much. Tryg actually started to create something called ACI because of this.

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

#104

Post by coldtea »

visarga wrote: post #37
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'm even happy they gave it a new name (Flux) because MVC frankly has gotten way too many definitions . Sad because there are too many definitions? Nothing a new name can't fix!

>Nothing a new name can't fix!

If a new name catches on and puts the plethora of older names in the dust, then it CAN fix the "too many names" problem.

And Flux seems to have latched on well.

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

#105

Post by d0m »

amelius wrote: post #102
joncrocks wrote: post #79

Earlier quoted context omitted.

From what I understand, react + redux has a couple of tricks up it's sleeve. As the components don't hold state, only display the state of the model (part of the redux store state), components only need to be re-rendered if the state has changed. If you combine this with reselect ( https://github.com/reactjs/reselect ), then this allows you to only re-render components when the sub-set of the state tree is changed th…

Does that also work if the dependence on the state tree is not hierarchical? I.e., subcomponents referencing the state in a random-access way?

It would be much easier if you provided an example of what you have in mind. The approach I mentioned work perfectly for us, but it doesn't mean it'd work for you.

But to answer your question, it shouldn't matter if subcomponents reference the state in a random-access way. Our workflow is like this:

a) Main components fetch data from an external module. (That module either queries the server, gets the data from the client database or uses something already in the memory cache).

b) That main component generates a ModelView state. Basically, it transforms the fetched data into something it can use. It could mean joining models together, etc.

c) The view uses the ModelView state to render itself. Each component generates a virtual dom representation and then renders themselves in the DOM.

d) Now, there are two different ways this ModelView state can be altered:

  1) From a global event (eg. New changes came from the server. Or a component elsewhere in the app sent a global event.)

  2) From the component itself (eg. An event/action is sent from the view)
e) Either way, once that ModelView state has changed because of that event, the view gets re-generated very efficiently. I.e. Only the small part that visually change gets rendered.

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

#106

Post by bobbytherobot »

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…

My take is you should be skeptical but don't let that skepticism stop you from learning something new.

I remember the complex UIs I and others wrote a decade ago with jQuery, now those aren't complex at all compared to what is common now. I feel that it isn't quite fair to say that back in the day we got along fine with just jQuery.

Speaking of Backbone, I was already more or less organize my code like Backbone for a year when it came on the scene. Then there is the question, can I really program a custom framework better than an established framework?

Post reply on HN