The server side style of MVC you describe is a far stretch from how MVC is practiced in retained-mode UI frameworks like UIKit, Cocoa, or Backbone. It’s possible to make this style work fine with careful design and planning; Apple built web versions of Pages and Keynote using SproutCore (which evolved into Ember?) in 2013-era.
In fact back then, everyone’s big app was MVC - usually Backbone. I worked on Airbnb’s host-side web app called “Manage Listing”, it had probably 30+ models, 150+ views, 100+ controllers in Backbone. There were many bugs in this scale of app around making sure the DOM reflected the latest change to some model. the engineering team regarded the more complicated screens as a nightmare to maintain in our fast paced environment with many teams touching the code.
Engineers at Airbnb started to adopt React as a solution to the problems we all experienced with MVC - not because it was a “hot new thing”. When React came out, it was widely regarded as weird - it was more like “eww, this smells of PHP and needs a weird compiler, but pure function of state is a lot better than fiddling DOM manually…”. Eventually we replaced Manage Listing backbone views with React components one by one until there was no backbone left.
React is still kinda weird but it does solve this problem the best out of the modern frameworks. It’s happy to over-render by default and prefers a correct DOM-for-state over everything else. It’s clear thought that the mental models popularized by React are worth it - now Apple and Google are switching to the React model in their own frameworks.
MVC is a proven and popular technology. It works very well, otherwise it wouldn't be so popular. I notice you allude to "problems we all experienced with MVC" without mentioning any. Surely if there are so many problems, you would be able to mention one?
I mentioned the main problem in the second paragraph:
> There were many bugs in this scale of app around making sure the DOM reflected the latest change to some model. The engineering team regarded the more complicated screens as a nightmare to maintain in our fast paced environment with many teams touching the code.
I've seen this same issue in Cocoa/UIKit/Android views. Older Cocoa in particular has a lot of hairy wiring up of signals and first responders and delegates. I think it's less of an issue there because the rate of change is typically lower; in web land we expect to deploy continuously and with a very high number of engineers, anything targetting the app store will usually deploy at most weekly (2 orders of magnitude fewer deploys) and with many less engineers (usually an order of magnitude at least. My hypothesis is the difference in change rate is why this kind of bug was more of an issue for web developers.
As parent pointed out, the MVC in server-side development only shares a name with the MVC in GUI development. Yes, MVC is a proven and popular name. But it means different things to different people.
Why would it be different? The concept of Models is the same whether it is client-side or server-side. These are objects that encapsulate business logic. The concept of Views is also the same. These are responsible for rendering the screen. The concept of controllers? That too is the same. Controllers determine application flow from one screen to the next.
The server is typically not a retained-mode kind of abstraction. Incremental view maintenance in retained-mode MVC systems is the main source of bugs. If you render the view from scratch on every request, it's more similar to React style immediate-mode UI than something like UIKit where you end up handling many UI events and keeping little bits of the UI up-to-date with model changes incrementally.
You can render the view from scratch on every user interaction, even in MVC. In fact, you can use React for that purpose. "Lots of people use React as the V in MVC." See that quote on this page: https://github.com/facebook/react/tree/015833e5942ce55cf31ae...
Personally, I have not run into large amounts of bugs of this type, and I have written plenty of MVC code using VanillaJS.
In fact back then, everyone’s big app was MVC - usually Backbone. I worked on Airbnb’s host-side web app called “Manage Listing”, it had probably 30+ models, 150+ views, 100+ controllers in Backbone. There were many bugs in this scale of app around making sure the DOM reflected the latest change to some model. the engineering team regarded the more complicated screens as a nightmare to maintain in our fast paced environment with many teams touching the code.
Engineers at Airbnb started to adopt React as a solution to the problems we all experienced with MVC - not because it was a “hot new thing”. When React came out, it was widely regarded as weird - it was more like “eww, this smells of PHP and needs a weird compiler, but pure function of state is a lot better than fiddling DOM manually…”. Eventually we replaced Manage Listing backbone views with React components one by one until there was no backbone left.
React is still kinda weird but it does solve this problem the best out of the modern frameworks. It’s happy to over-render by default and prefers a correct DOM-for-state over everything else. It’s clear thought that the mental models popularized by React are worth it - now Apple and Google are switching to the React model in their own frameworks.