Live data from Hacker News

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

medium.freecodecamp.com

91–100 of 106 posts

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

#91

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…

I recently started diving into Vue.js (2.x) It's fantastic. It's a utopian Angular1. The html syntax is fairly similar, but cleaner and less verbose.

Vue-router is what really got me into it. Again, it's similar to UI-router for ng1, but destroys it in simplicity and readability. I'm using their vue-webpack template to rebuild my site and it's going great.

Personally, the best thing for me is that a component gets nearly everything it needs in one file. Template, script, and scoped styling? Exactly what I've always wanted. Forgive the gushing review, but honestly, I haven't ever been this excited about a technology. Not ng1, not webpack or es2015, or [fancy new tech]. This shit just works.

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

#92
I worked with MVC before, but eventually I found that DDD (Domain Driven Design) is what I'm looking for. Domain Driven Design is more like a set of rules of how to apply the existing design partners (eg: repository, factory and aggregation) and building blocks (eg: layering architecture) to design your business models and keep the integrity, invariance between data. Moreover, it lets you easily define the boundary between your services for Microservice architecture.

MartinFowler DDD blogs: http://martinfowler.com/tags/domain%20driven%20design.html Book: https://www.amazon.com/Domain-Driven-Design-Tackling-Complex...

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

#93

Earlier quoted context omitted.

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 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 than us.

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

#94
A component, a la React, is merely an opinion on MVC. M are props, and V is a pure function of these props. React encourages both M and V to live in the same file, which is a deviation from best practices in MVC land. But there is still an M and a V.

C, in the front-end world, has less of a direct equivalent, but can be thought of as your router, which React also has as a separate entity.

What MVC does not have an opinion on, is that the M is really one giant object, where each component receives a sub object of it. Where MVC can go wrong is when many objects have dependencies between their state. React comes along and says that two objects with a dependency should derive this shared state from something above them, not inside them. This is a useful pattern. It is still merely an opinion on how to organize Ms in an application. It is not something "different".

In functional programming, in its purest sense, there is no M. That's different.

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

#95
post #83
post #69

Earlier quoted context omitted.

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.

I think that's what I'm driving at: apart of the Om architecture itself, does it make sense to drop something like a CSP autocompleter into an Om app, or are those things incompatible?

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

#96
Great article, couldn't explain the pain better. I worked a lot with Angular1 in the past couple years, and the controllers tend to get very messy because a lot of ui state and app data mixed together in the controllers. I am using React for most of my apps now, but I look forward to see what frontend architecture will come out in the next few years. I feel as ES6/7 is getting more and more common for js development, probably some OOP patterns that are used in Java/C# will be developed for frontend, but of course, front end apps is still different from Java server apps because of the nature of the language and the purpose of the app (frontend is more view and user interaction oriented)

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

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

The problem with that is always what the frontend kids call "responsive" these days. The D&D editor doesn't infer a layout, so when you resize stuff stays the same or everything resizes equally, which is terrible.

I think the XAML approach was ideal, where you had a design view that showed a rendering of your view and allowed to make property changes and D&D controls, but also had the source to properly use grids and other layout managers to align and resize components.

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

#98

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…

So...according to your definition MVC == encapsulation ?

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

#99

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…

check out http://aurelia.io

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

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

It's funny how this anti-pattern like has become so widely accepted.
Post reply on HN