[nikisweeting]

This is the key line that the original article is missing imo, which solves much of the headache that they claim exists with message passing/raising state:

> a view updating itself from the model should never trigger transactions on the database

i.e. a view rendering from state/messages, should never re-emit new state/messages.

[Chris_Newton]

I thought the article was too dismissive of concepts like MVC, immediate mode and functional programming, given that ideas coming from those directions might offer the answers the original author is searching for.

The separation of an underlying data model from any particular way of presenting its current state is a powerful idea that has proven its value many times. We’ve used it to build user interfaces, from early GUIs when we didn’t yet have the kinds of libraries and platform APIs we enjoy today, through games with unique rendering requirements and a need to keep frame rates up, to modern web and mobile app architectures. The same principle is useful for building non-user interfaces, too, in areas like embedded systems where you are “presenting” by controlling some hardware component or distributed systems where you are “presenting” to some other software component as part of the larger system.