[nschiefer]

(Disclaimer: I’m plugging my own work here ;-))

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.

[PKop]

Good essay. Particularly with web development, there is complexity around bridging the gap between server and client, and data crosses this chasm through serialization which exacerbates the problem and limits expressiveness of server languages, requiring massive duplication of code simply to serialize and duplicate on client what is present on server if one wants all the power of client interactivity and API's.

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...

[1] https://news.ycombinator.com/item?id=31979347

[vaughan]

That article was a great read.

> 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.