And this rich desktop way is probably where the second acronym originated, MVVM. Don't be fooled by the letters, by the omission of the C. Controllers are still there. They need to be. Nothing gets removed. We just add one thing: statefulness, data cached on the client (and along with it intelligence to handle that data). That data, essentially a cache on the client, now gets called »ViewModel«. It's what allows rich interactivity. And that's it.
MVC = model, controller, view = essentially one-way communication = poor interactivity
MVVM = model, controller, cache, view = two-way communication = rich interactivity
We can see that with Flash, Silverlight, and - most importantly - Javascript, the web has embraced MVVM. Browsers can no longer be legitimately called thin clients. Look at their programmability. Look at their memory consumption. Look at all the Javascript interactivity on modern web pages.
Personally, I find this theory and acronym business easier to understand by looking at what it's referring to in concrete reality. Abstract concepts are useful, especially when demonstrated on concrete matter, so understanding may come full circle.
Vue.js is focused on the ViewModel layer of the MVVM pattern. It connects the View and the Model via two way data bindings. Actual DOM manipulations and output formatting are abstracted away into Directives and Filters.
Some things that Controllers, Presenters, and ViewModels have in common are:
Thin layers They communicate with the model and the view The features of each.
they are used for different goals/projects. depends on needs.
wikipedia: "MVVM was designed to make use of data binding functions in WPF to better facilitate the separation of view layer development from the rest of the pattern, by removing virtually all GUI code (“code-behind”) from the view layer.[9] Instead of requiring user experience (UX) developers to write GUI code, they can use the framework markup language (e.g., XAML) and create data bindings to the view model, which is written and maintained by application developers. This separation of roles allows interactive designers to focus on UX needs rather than programming of business logic."
as it turns out there isn't much difference but MVVM is more versatile and later technology
and here my personal conclusion (lifted from http://joel.inpointform.net/software-development/mvvm-vs-mvp-vs-mvc-the-differences-explained/) Today, I think developers are opting for MVVM (or MVP) over MVC in most situations where this feature of MVC would have been used. Websites are a situation where I think MVC is still a very practical solution. However, the view is always disconnected from the server model and can only receive updates with a request that gets routed through the controller. The view is not able to receive updates directly from the model.