Our motivation

Motivation

We were not happy with the currently popular event-sourced state management, and that logic is usually dependent on the presentation structure. This is mainly caused by the nature of the applications that we usually develop: data-driven admin solutions with server backends.

From our point of view, using event-sourced state management such as Redux for the presentation layer is usually quite complex, makes the application hard to reason about, and requires a significant amount of boilerplate code. For example, take a simple master-detail screen with an edit form and validation - the code necessary for this ordinary scenario was a big issue for us. That's why we embrace the MVVM model, where ViewModels handle the presentation state. Please note that we are not against event sourcing, especially on the backend side. That is an entirely different story!

Even though the application logic is usually separated from the presentation part, there are still many places where it leaks to the view code (e.g., navigation/routing, validation, etc.). As we see it, existing solutions seem only to fix the symptoms, not the root cause. The cause is the View-first approach. If you start with views, you need to handle navigation, application structure, and so on in views, which should not be their responsibility. That's why we wanted to start with ViewModels, thus model the application from the logical point of view, and just after that project it to the actual user interface.