Furthermore, MVC is, when done correctly, a sane two way data-GUI binding. However, I have never seen a sane implementation ;-)
I'm honestly amazed some (especially undo!) were shrugged away so easily.
Text editor? Those have undo.
Image editor? Also have undo.
Video Games? Depends. Should you be allowed to "undo" in a game of minesweeper? Probably not- it kind of ruins the game. Should you be allowed to "undo" in Chess? Probably not. Should you be allowed to undo in Solitaire? Maybe.
Chat client? What would you undo? Can't unsend a message.
Web Browsers have back buttons, to the extent that those can undo.
I could see file managers maybe having undo. I honestly don't know if the popular ones today do or not.
What apps are missing undo functionality for you?
They also seem to support app development for Android: https://wiki.lazarus.freepascal.org/Portal:Android and iOS: https://wiki.lazarus.freepascal.org/Portal:iOS
Some time ago they acquired a cross-platform component library, FireMonkey[2], which does not use native controls.
[1]: https://docs.microsoft.com/en-us/windows/win32/controls/indi...
[2]: http://docwiki.embarcadero.com/RADStudio/Sydney/en/FireMonke...
MVC can be used in its place, but it would often introduce unnecessary complexity, e.g. additional controllers.
MVC works for contextually equivalent interaction, which is still very useful, too.
Mostly just do what makes sense.
The challenge is, as it has been, how to be flexible, smart, and forward-looking, but developing quickly for what’s needed now.
But whether you’re coding a quick prototype or designing a large project (which is risky because a feedback loop from all users may be longer), focusing too much on the how and specifics instead of the overall experience may get you into trouble later.
For example, you could have what sounds ideal: microservices, individual teams each working on them focused on their own goals, powering a site with the latest, well-used JS framework, able to deploy quickly and developing quickly with a lot of fun-but-professional-looking communication, and end up with a slow, broken application.
what about inputs? or do you consider them stateless because their entire¹ "state" is reflected in the DOM, i.e.
<input type="checkbox"/>
// *click*
<input type="checkbox" checked=""/>
¹ - well, except focus, open/closed for <select>, and probably a bunch of other things
Applications on the other hand start their lifecycle as a singleton and because you can guarantee a parent child relationship from top to bottom it tends to facilitate design patterns with sharing of state more easily between pages.