Detailed UI state like scrollbar position usually isn’t interesting in the sense that you would need to directly respond to it, share it, persist it, etc. That’

Detailed UI state like scrollbar position usually isn’t interesting in the sense that you would need to directly respond to it, share it, persist it, etc. That’s why you don’t usually include it in your application model. State being collaborative is precisely the problem. If all the components owned important state, they would need to share it with each other. This gets real complicated very quickly, especially when multiple parts of the app need to change that state. So the main proposition of Elm is exactly that separate components should not hold important state and whatever that needs to be shared should be centralized and modified in one place. Which sounds like the God Object antipattern, but is not, mainly because you can only change the state indirectly, by sending well-defined messages.