Live data from Hacker News

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

medium.freecodecamp.com

61–70 of 106 posts

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

#61
post #42

At the moment I'm sold on Mode-View-Intent, which is more delarative and non-OOP. I also have the feeling it lets me compose a bit more easy. DOMStream = view(model(intent(DOM))) DOMStream.subscribe(render) intent() takes the DOM, wires up some interactions and returns streams "of" these interactions model() takes streams of interactions, wires them up with data retrieval and mutation streams and returns these data-s…

> model() takes streams of interactions, wires them up with data retrieval and mutation streams and returns these data-streams

I think that's called a controller or presenter in other patterns.

Actually your view and intent also do what a controller would do. The DOM is your actual view, and your data your actual model.

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

#62
post #50
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…

I'm a web dev since the beginning. Of all the frameworks I've worked with, Knockout has the most utility for the least obtrusiveness.

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

#63
post #42

At the moment I'm sold on Mode-View-Intent, which is more delarative and non-OOP. I also have the feeling it lets me compose a bit more easy. DOMStream = view(model(intent(DOM))) DOMStream.subscribe(render) intent() takes the DOM, wires up some interactions and returns streams "of" these interactions model() takes streams of interactions, wires them up with data retrieval and mutation streams and returns these data-s…

> model() takes streams of interactions, wires them up with data retrieval and mutation streams and returns these data-streams I think that's called a controller or presenter in other patterns. Actually your view and intent also do what a controller would do. The DOM is your actual view, and your data your actual model.

You're right, the names are badly choosen.

In every function the same is happening, streams are created/wired up with other streams.

The differentiation here seems to be, that the Model function just wires up streams for the data, the View function just wires up streams for the display and the Intent function just wires up streams for the interactions.

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

#64
post #35

Earlier quoted context omitted.

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.

JavaScript isn't a type of logic, it's a language. You wouldn't say JavaScript is the M in MVC, for example. If you have JS in HTML, and that JS code is strictly view logic, then your code still has a clear and useful separation of responsibilities.

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

#65
post #41

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

The "jQuery === bad code structure" association is strong, even today. But the fact is you can write good code with jQuery – without Backbone – just fine.

Most all web developers of that day were new to programming (experienced folk didn't take JS seriously), so naturally they did not know how to write well-designed software. The benefit of Backbone was not Backbone itself – it was the community push for thinking about code structure in general.

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

#66
post #35

Earlier quoted context omitted.

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.

> now we have Javascript being mixed with HTML

Now we have JavaScript mixed with an HTML-like syntax.

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

#67
For anyone interested in a surprisingly pleasant to use front-end MVC framework I am a huge fan of http://mithril.js.org/.

It espouses a (I believe?) slightly more traditional MVC interpretation where your Controllers are usually extremely light and in most cases completely optional. It encourages a MVVMC (Model View View-Model Controller) approach to encapsulate view-state.

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

#69

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

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 said yes but that was the extent of the conversation.

In particular, I have yet to see any examples of integrating the CSP approach with React or similar architectures. For example, can you hook a process-based autocomplete widget into a React view? Is anyone doing this or have we rejected CSP for UI logic? I am interested if you can find article you mentioned.

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

#70
post #56
post #48

Earlier quoted context omitted.

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…

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.
Post reply on HN