You can also use the component abstraction but choose not to use getInitialState/setState -- but our goals are to provide a component abstraction that is flexible enough to meet people's needs while still being restrictive enough for us to build higher-level optimizations around them.
Without explicit functions to be called, you can't detect state changes and would need polling. This is terrible.
At the end of the day, it's a limitation of JavaScript because unlike with Python, for example, you can't have automagic getter/setter functions. They have to be called as functions.
http://www.html5rocks.com/en/tutorials/es7/observe/
Also you could just re-render whenever any event happens, which is probably when your state changes anyway.
So far exists only on Chrome and Android browsers.
https://groups.google.com/forum/#!msg/reactjs/R61kPjs-yXE/ys...
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...
AmpersandJS, for example, implements its observable pattern in this way:
http://ampersandjs.com/learn/state
That said, I don't think the pubsub/rx/observables pattern is the most optimal for UI development, since it still allows for cascading event chains. Modeling all application state as a large data structure that allows for efficient diffing — which nicely mirrors the diffing react does with both it's internal component tree and diffing with the DOM — is a much more straightforward approach. Just re-render your application 60 times a second, like a game engine, and make that process as efficient as possible.
As another commenter mentioned, explicit `.setState` makes it much easier to see where in your code you're triggering changes. It also helps you think, "okay, I am mutating the state here... is that really what I want to do?"
Because Mithril uses plain JavaScript constructs, you can use standard design patterns and techniques when constructing and managing your components. Everything works beautifully.