You might enjoy this project, which ties to do basically exactly what you described: stick everything in a database and let it drive the app: https://riffle.systems/essays/prelude/
It’s still very much a research prototype but we should have some more writing out soon.
This is a big value of recent server-centric frameworks like Phoenix LiveView that provide ability to have code and data co-located and not have to duplicate so much on client and server as with SPA's while attempting to maintain some base level of client interactivity. But seems always a tension between leveraging the full power of client and full power of server.
You might find this article [0][1] informative. It disputes the idea that UI's are "pure functions of the data/model" in a compelling way, and points to this incorrect assumption as having introduced some complexity/pain in how frameworks like React work.
[0] https://blog.metaobject.com/2018/12/uis-are-not-pure-functio...
> What is a (somewhat) pure mapping from the model is the data that is displayed in the UI, but not the entire UI.
This line was interesting to think about.
React added so much complexity and perf issues, and I really don’t know what was so bad about something like Backbone / Backbone.Marionette.
I find that in React I want all component props and data to come from an external store via subscription, instead of being passed down some tree. My UI is stable.