Application-specific event loops in JavaScript UIs

(A longer version of https://news.ycombinator.com/item?id=6074054
re application-specific event loops in JavaScript UIs.)

From a complexity point of view, if your UI can easily be modeled in
terms of a stream of mouse-clicks, keypresses, and so on, then this
design gains you nothing. It just duplicates the browser loop at a
higher (i.e. slower) level. But if you're trying to make, oh I don't
know, say a spreadsheet, where the UI can't easily be so expressed,
there's a lot to be gained from a single interception point that takes
the lower-level events and translates them into app-specific ones.
That way you can move just once (and in just one portion of the code)
from the lower level to the higher, instead of writing the entire UI
in terms of both and suffering a thousand conflicts between them.

That might sound obvious, but it was a revelation to me when I saw
that you could write a UI like this; it is a way out of the
event-handler spider webs that I always used to get trapped in. I
think the reason I didn't see it before is that that interception
point has to be put right at the root of the connection between the
browser and the app; that means digging deeper and writing code that
one normally thinks of as outside the scope of an app UI. It's as if
one is laying a deeper foundation in order to erect a larger building.

This design is particularly powerful when what's going on in one part
of the UI needs to change something that's typically handled
elsewhere--something that comes up frequently in complex UIs, which
after all are highly stateful. The obvious way to do it is to just let
the one thing call the other, but now you've got coupling which when
compounded will lead to spaghetti. Another way is to generate fake
low-level events (e.g. "pretend to click the mouse here") and let
normal event handlers pick it up. But translating between levels like
that is a real pain, and this approach never works very well anyway
(i.e. such pretend clicks never seem to behave like a real one would
have). In the above design, you just make an application event and add
it to the queue and it's guaranteed to be handled the same way as any
other. If you've worked out a good model for your UI then these events
are basically messages in a language that the entire UI shares. That
reduces the coupling enough to get you off the path to spaghetti.

From a performance point of view: if your code is doing things in
event handlers that make your app sluggish, that's a really bad
position to be in. For example, you can't (well, I couldn't) easily
drop scroll events in a way that lightens the browser's load and makes
it faster. But if your browser event handlers do nothing but trivially
append to a queue, they basically can't bog down. And since you're
running your own control loop on a timer, you now get to decide how
much of anything to do and when. You can make these decisions in an
app-specific way instead of relying on the browser which has no choice
but to decide things the same way for everybody. This opens a new
world of strategies for keeping UI latency low. It also gives you
simple ways to simulate concurrency.

I know there are a great many ways to solve these kinds of problems,
but this one pleases me considerably for two reasons: it saved us from
some horrifying (potentially fatal) performance problems, and it
transcends the usual engineering tradeoff between abstraction and
speed—always a very interesting thing to run across.