More or less related; one of the nicest paradigms I've used for handling UI was concurrent lightweight processes with synchronous channel-based communication. That's a mouthful! But it's essentially the model languages like Go use. In fact, Rob Pike has written one of the conceptual ancestors to Go, Newsqueak, specifically to deal with UI.
In that model, each 'thing' on the screen runs as a concurrent process, but it's written as a simple loop which blocks on reading from the input channels (mouse, keyboard events, etc.). This makes the behaviour of each element clearer to read, and possibly easier to compose. Compare that to the callback spaghetti of event driven systems like JS in browsers and you'll see a clear winner.
Keep in mind that the work linked in the post is about synchronous reactive programming, which is a very different beast from UI programming (which is still reactive, but much more asynchronous and has not much to do with real time!).
In that model, each 'thing' on the screen runs as a concurrent process, but it's written as a simple loop which blocks on reading from the input channels (mouse, keyboard events, etc.). This makes the behaviour of each element clearer to read, and possibly easier to compose. Compare that to the callback spaghetti of event driven systems like JS in browsers and you'll see a clear winner.
http://swtch.com/~rsc/thread/newsqueak.pdf