Article claiming that MVC is dead

79 views
Skip to first unread message

Matthew Browne

unread,
May 27, 2018, 10:18:03 PM5/27/18
to object-co...@googlegroups.com

FYI, this is the sort of talk that has been circulating in the frontend web development community for the last several years:

https://medium.freecodecamp.org/is-mvc-dead-for-the-frontend-35b4d1fe39ec

It inspired me to provide some context that was sorely lacking in the article. I just posted this comment:

~~~

This article isn’t all bad, but it defines MVC extremely narrowly and with a very short-term and distorted view of history. And it misses by far the most important aspect of MVC — facilitating UIs that allow the computer to become almost an extension of the user’s mind, improving the user’s experience and making applications more intuitive. This is achieved through understanding the mental models of the users and stakeholders and reflecting that both in the UI and the source code, particularly in the “M” of MVC. MVC was invented by Trygve Reenskaug in the 1970s. In more recent years, Trygve switched his focus to a new programming paradigm called Data-Context-Interaction which is complementary to MVC, and which addresses the concerns about business logic mentioned in this article by creating a clear place to consolidate such logic and make the code generally more readable. In 2009 if not earlier, he and his collaborator on DCI, James Coplien, started referring to MVC as MVC-U to emphasize the importance of the users’ mental models as an essential part of the pattern.

Now to get into the more technical aspects…I would say that React and Flux (unidirectional data flow) is actually a lot more compatible with Trygve’s original MVC vision than people realize. Since it was invented in the 70s, obviously things were quite different than they are in modern-day web development where you have a separate frontend and backend. As others have commented here already, the original MVC was actually much closer to MVC frameworks on the frontend and even React/Flux than it is to server-side MVC. Server-side “MVC” is certainly a useful way to separate concerns, but calling it MVC was incorrect from the beginning. If it was trying to be faithful to MVC, it usually failed by putting way too much business logic in so-called “Controllers”.

And here’s something that most web developers these days will find really surprising: in the original MVC, the usage of the observer pattern was entirely optional. So all this talk about the downsides of coupling Views and Models and allowing them both to observe each other automatically isn’t even an argument against MVC itself but rather just one implementation of it. And although React and Flux introduce a lot of new terminology, if you define MVC a little more loosely then IMO it’s still very similar… As explained in “The Model-View-Controller (MVC): Its Past and Present” (https://heim.ifi.uio.no/~trygver/2003/javazone-jaoo/MVC_pattern.pdf), M V and C are really roles that can either be played by the same object or separate objects depending on the situation. React components usually play the View role but can also act as Controllers when they coordinate multiple sub-components. The Model is usually outside React (managed in Redux etc.) but in simple cases, internal component state is used to manage the behavior of a component, so the component is acting as both a Model and a View.

Still, I recognize that there are certainly a lot of differences between the typical modern-day React architecture and the way MVC was used in the early days in desktop software. I’m not even sure if it’s necessarily helpful to describe the Flux architecture in MVC terms as I did above, but my point is that MVC is definitely not dead and I think modern-day web developers would benefit by understanding more of the history and reasoning behind the original pattern. I asked Trygve some questions about MVC at the beginning of last year and I think this quote from his reply is very relevant here:

“I don’t see MVC as a straight jacket, but as an inspiration. I let it guide my implementations, but not constrain me when other solutions are clearly more readable.”
https://groups.google.com/d/msg/object-composition/vZqfcPA1hKY/RX67PNrnEwAJ

Regarding this article, it’s not the author’s fault that he missed all this context, since no one is teaching frontend developers this history. If I had not encountered DCI several years ago and learned more about Trygve and his work, I probably wouldn’t have learned about this either. For those interested in learning more about this, first check out the page about MVC on Trygve’s website:
https://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html

And here’s a great overview article by Andreas Söderlund:
https://github.com/ciscoheat/mithril-hx/wiki/Rediscovering-MVC

Daniel P

unread,
May 28, 2018, 6:04:12 AM5/28/18
to object-composition
On Sunday, May 27, 2018 at 10:18:03 PM UTC-4, Matthew Browne wrote:

FYI, this is the sort of talk that has been circulating in the frontend web development community for the last several years:

https://medium.freecodecamp.org/is-mvc-dead-for-the-frontend-35b4d1fe39ec

It inspired me to provide some context that was sorely lacking in the article. I just posted this comment:

~~~



Thanks for the link. Are you familiar with the MVVM pattern used in Microsoft WPF development?


What the author of your link calls "Components" sounds a lot like ViewModel in MVVM. "Components" seems an awful general term to label that.

Daniel

Matthew Browne

unread,
May 28, 2018, 6:39:18 AM5/28/18
to object-co...@googlegroups.com
I should have mentioned that the article was apparently written for frontend developers with at least a cursory familiarity with React. "Component" in the article refers to a React component. In React, components are usually UI components - anything from a button to a date picker to a fancy app-specific layout component that composes other components. Components always have a render() method to render the UI, but it can be a parent component that just renders other components (or even returns null, meaning don't render anything) and acts as more of a Controller, so they're not used only as Views.

Sent from my Android phone

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.
To post to this group, send email to object-co...@googlegroups.com.
Visit this group at https://groups.google.com/group/object-composition.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages