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

81–90 of 106 posts

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

#81

Post by nwienert »

We've sort of evolved in our stack, which leans heavily on two less-popular options (MobX + Horizon), towards a pattern that I now think of as invaluable.

I started calling it Model-View-Store recently as I think that best describes it. There are a few unique things here that I think are valuable.

Starting with Models: Models all return observable values. So if I query for a single record I get back an observable object, or a list, observable array. I define `@query` decorators on the models to set up these queries. Model's include prop validation, normalization, consistent operation names, and more.

Views come in two types: application and presentational. App views are all decorated to automatically react to mobx observables, so you can literally have a Model `Car` and in a view call your query `Car.latest()`, and your view will trigger the query and react to it accordingly. One line model view connections!

Then you have Stores: they are just logical containers for views. Any time a view needs to do more than some very simple logic for a view, you can attach a mobx store to it with very little code. Stores also can manage the data from the Model (and because the Model returns observables, this is usually a one-liner). But they don't have to. Stores are located side-by-side with the views they control (and are be passed down to sub views when needed).

I've been working on this system for a bit now along with our startup and we've been able to deliver some pretty incredible stuff very quickly. Having a consistent model system is crucial, I can't imagine programming without having prop validation and a single place to look for my model queries.

Going to be releasing pieces of it over coming weeks and hopefully a full stack example thats really legit soon.

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

#82

Post by sametmax »

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…

+1

Everything right now is just MVC-like. Yes you have some unidirectional PUB/SUB here or some immutable data structure there.

So what ? In the end, you still have the separation between the data, the way you manipulate the data, the way you display the data and a canal of communication for those.

This is the essence of MVC, and what everybody is doing right now is just a variation of it.

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

#83

Post by nickik »

shoover wrote: post #69
Davertron wrote: post #45

Earlier quoted context omitted.

The CSP thing is something I've been looking at recently, and while it seems like it's a little bit lower-level than things like Rx, it seems like channels are more flexible streams (i.e. channels are two-way so you can do back-pressure etc.). I've been playing with https://github.com/ubolonton/js-csp and it's pretty nice; the "yield" statements everywhere are a little wonky, but otherwise it seems like you can imple…

Those articles are excellent and held my interest since they were published, but at the same time React and Flux were exploding and I never saw any further talk of modeling UI logic with processes and channels. It is still in my notes: Take another look at Hoare CSP for UI programming perspective. I once asked David Nolen on twitter if he thought the CSP approach is still useful given the perspective of React/Om. He…

David has moved away from it, in OM.next you do not use CPS. You can of course, but it would only be a implementation detail and not fundamental to the structure of Om.next.

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

#84

Post by revelation »

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…

The absence of standard widgets makes React awesome?

People compose an entire screen from built-in widgets because usable widgets and layout algorithms make this possible. If you are trying to build more complex screens, people in "classic desktop and mobile UI toolkits" also build own widgets.

Projects like Material-UI are finally dragging frontend development into the 1990s of "classic desktop UI toolkits", only the layout functionality is still sorely missing.

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

#85

Post by mpweiher »

lcarlson wrote: post #54
prance wrote: post #21

Earlier quoted context omitted.

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

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 on both M and V, and thus both proliferate and are not reusable.

Glue code. The dark matter of programming.

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

#86

Post by [deleted] »

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…

[deleted]

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

#87

Post by greenshackle2 »

glenndebacker wrote: post #75
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…

"According to the consensus, I should have gone with Backbone.js in 2011 (then Knockout, Ember, Meteor, Angular…)" The best investment that I ever did was really learning JavaScript and all it shortcomings. The problem with a longer younger colleague's at work is that they seem to learn frameworks instead. They can make cool stuff but from the moment they are in situations where for example "this" does weird stuff, t…

That's the problem with all abstractions.

The abstraction gives you hope that you won't have to worry about the low level details, it will be so easy.

But almost invariably, the abstraction breaks down or acts weird, or some low level error or limitation bubbles up, or the abstraction has horrible performance for some edge cases.

So now, where you had 1 problem - the low level thing - you have 2 problems - the low level thing, and the abstraction.

You don't have to be a uber-expert in the low level thing but it's really helpful to be comfortable with it.

I see it with ORMs - 'wow this is magic, I never have to do SQL again' - 'oh crap, a weird edge case, I have to do SQL' - 'oh crap, why is this so slow, guess I have to look at the generated SQL, and maybe hand-roll my own'.

(Not saying you shouldn't use abstractions, they can save a lot of work for the central cases where they work right.)

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

#88

Post by TimJYoung »

wslh wrote: post #34

Am I the only one thinking this kind of discussion is not hitting the nail on the head? I think the main issue with web UIs is the lack of good UI design tools, and nice and robust components. When I am developing a UI I am spending a lot of time writing code code while I just want to drag and drop components.

There are products out there that work like this. Our product, Elevate Web Builder, is one of them:

http://www.elevatesoft.com/products?category=ewb&type=web

although I'm not sure how many more there are that aren't hosted directly in the browser, as opposed to a standalone IDE that runs on a desktop OS.

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

#89

Post by thom »

jhund wrote: post #78
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…

Well said! I find that https://github.com/Day8/re-frame combined with statecharts fits the bill and makes for some incredibly clean and enjoyable UI development.

How do you architect your re-frame apps? How do you decide where dispatch/subscribe gets called? I ask, because having worked on a couple of re-frame (and indeed raw reagent) projects, I often see issues of layering and responsibility that MVC traditionally solved.

For example, I regularly see subscriptions deeply nested in the component hierarchy, instead of more 'pure' components that just accept data at the top level. This leads to controller-style logic spread all over the app. I see the same issue with events - dispatch being called from inside view components, and despite the event abstraction, what you basically end up with is mutable state spread all over the app.

Happy to admit these apps probably aren't shining examples of react/reagent/re-frame architecture, but I'd be interested to see some canonical architecture guidance.

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

#90

Post by Silhouette »

lmeyerov wrote: post #23
Silhouette wrote: post #14

Earlier quoted context omitted.

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

We went the reverse: fine-grained to coarse-grained. The "aha" is that the speed is just not a big enough deal for most cases. Consequently, go full declarative for the 95%, and only go fine-grained for the 5%. More concretely: we went from mostly Rx to mostly React. Both have their strengths, but it's not a 50/50 thing in terms of lines of code.

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 scales very well to more demanding environments, though. If your model has significant constraints between the data points that need to be enforced or you need non-trivial view-state between your model and your rendering code, you're back to having dependencies in the data that need to be implemented somehow. That is outside React's scope, so something else needs to bridge the gap.

I find React's design itself also struggles with scaling up beyond a certain point, though it's a high bar that I expect most UIs running in browsers wouldn't reach. However, if you're implementing something like a complicated dashboard with many data dependencies and interactions, you start needing shouldComponentUpdate almost everywhere to achieve acceptable speed. That has profound implications for how other parts of your app are structured because you need some way to make shouldComponentUpdate fast, and it can also lead to more and sometimes artificial subdivisions of your rendering components so you can use shouldComponentUpdate at the necessary level of granularity.

Overcoming those scalability issues usually seems to bring me back to the approach I mentioned before for larger, more complicated UIs: data dependencies are handled through some sort of observer model and/or lazy queries, but a library like React is still useful for declarative rendering of each smaller part of the UI so you don't have to worry about transitions most of the time.

Post reply on HN