MVC and MVVM
The biggest difference between these two is that the second one adds a reactive modern frontend framework. It used to be the controller driving page updates, all by hand, but now as soon as the data changes the framework takes over on its own, which is reactive updating. Of the two Vs, one is still View, and the other is ViewModel, a layer designed specifically for reactively updating the page. C no longer manages page updates by hand, it delegates all of that to the framework.
Strictly speaking, MVVM here means a framework with a view and data binding, and most implementations are two-way. React is a bit special, its data flow is one-way, and Angular is not quite the same. Two-way binding does feel great, but once the scale balloons it gets really messy, and sometimes I don’t want data updated in both directions. React has made you write it by hand from its original design onward, which counts as a way of forcing you to manage it, but it gives up convenience.
Angular’s new Signals feature is worth talking about. At first glance it looks a lot like React’s state mechanism, both updating only the parts of the UI tied to the data that changed, but the mechanics behind them are very different. React relies on a vDOM, and every update has to run a diff, which costs performance once things get big. Angular’s signals go straight to the DOM to update it, no comparing at all. A signal here is essentially a subscription bound to the DOM, like an agreement between you and me, the data changed so I tell you directly, instead of asking everyone every time and comparing.
MVC on the backend refers to the standard structure we use now, Models, Controller, Service. They handle defining the data structures, HTTP preprocessing and routing, and the actual business handling. It’s pretty much the same as the frontend, and the biggest difference is that V is controlled by C, you finish everything on the backend and then throw it over to the frontend. So at the start the two were one and the same. Later on, as web apps got more and more complex, this whole setup got moved straight over to the frontend, where V went from the entire html to the DOM objects you operate on directly. But since the interaction between the data layer and the rendering layer is such a pain, all sorts of frameworks came along after that to separate plain M from VM, and that’s how MVVM ended up with two Vs (one of them a mapping of V, the ViewModel). Rendering updates caused by data changes are handed to state in the architecture, which manages them exclusively, and C no longer operates them directly. C’s job gets split up from here. When things aren’t complex you don’t need to add it separately at all, and when they get more complex it becomes the part that manages state in one place.
Translation note. I wrote this in Chinese. This English version is an LLM translation, so the wording is not mine even though the thinking is. Original: MVC和MVVM.