Live data from Hacker News

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

medium.freecodecamp.com

41–50 of 106 posts

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

#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. It has its flaws -- as any old codebase will -- but I'm happy they went with Backbone. I'd probably be saying the same thing for the other frameworks mentioned.

Its easy to point out all the flaws from our past. Much more difficult to predict how thing will be in the future. Making a choice now, even the wrong one, is almost always better than clinging to things that are known to not work.

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

#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-streams

view() takes the data-streams and uses them to create DOM mutations-stream, which it returns.

The nice thing is that these observable streams are really nice to filter, map, debounce etc. Also, it helps with fast realtime data stuff, because you can easily wire up these fast streams with a tiny part of your app and the rest of it won't even notice (which is a bit ugly if you got a big state-tree that represents your whole app state).

The not so nice thing is, that controlling them completely declaratively has a steep learning curve.

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

#43
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.

When has drag and drop ever worked for any programing environment?

VB6? Delphi? Windows Forms? WPF? Flash? QT? Xcode?

I am not saying I don't want to write a single line of code, just saying that the UI components can be assembled and "configured" with a design tool.

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

#44
post #37
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!

https://xkcd.com/927/

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

#45

> 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 implement some pretty sophisticated concurrency between processes with pretty straight-forward code.

For examples of that sort of thing, David Nolen and James Long have written some really great articles on the subject:

http://swannodette.github.io/2013/07/12/communicating-sequen...

http://swannodette.github.io/2013/07/31/extracting-processes

http://jlongster.com/Taming-the-Asynchronous-Beast-with-CSP-...

There was also an article recently that described a flux-like architecture using channels that I found pretty interesting, but I can't track it down right now.

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

#46
post #43

Earlier quoted context omitted.

When has drag and drop ever worked for any programing environment?

VB6? Delphi? Windows Forms? WPF? Flash? QT? Xcode? I am not saying I don't want to write a single line of code, just saying that the UI components can be assembled and "configured" with a design tool.

Having started on Android and then gotten into a Delphi environment, Android development tools seem like they're directly evolved from Delphi.

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

#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 data, no logic) and the Controller (Business logic receiving commands/actions/called/whatever which changes the states and let the view knows that it needs to update).

Is that pattern dead? Far from it.

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

#48
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)?

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

#49
post #13
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…

The Model, View, Controller terms were originally defined by Trygve Reenskaug in 1978, based on his Smalltalk involvement, and formalised as Models-Views-Controllers in a 1979 paper.

He tells the story on his homepage: https://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html

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

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

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 successfully in huge projects.

Post reply on HN