Entity-Centric Architecture: A Different Way to Think About Web UIs

This is the second post in a series. Start with the first post if you haven't already. In the first post I argued that the real problem with modern frontend frameworks isn't performance or verbosity — it's locality of reasoning. You can't look at a line of code and know when or why it will execute. I also laid out the case against signals, composables, and runes specifically: they shift the problem rather than solve it, trading one invisible system for another. This post is about what the alternative actually looks like in practice — how the entity-centric model holds up beyond a counter example, where it fits, and where it honestly doesn't. The Component-Centric Assumption Every mainstream framework is built on the same foundational assumption: the component is the unit of composition . Logic lives in components. State is owned by components or lifted up from them. The UI is a tree of components, each responsible for its own piece of the world. This model works well for many applicati