Decoupling Web Application Eventing from the DOM

Sometimes I think, I write things which make no sense at all. Then I frame them up for farther consideration.

TL;DR: Can you guys tell me about programs which:

1. implement "events" and "event listeners" ...
2. ... on web clients... (not servers)
3. ... outside of the the DOM (events are not attached to DOM elements)

?

---

I just found a bug in common web applications. This has been bugging me for some time, and I'm relieved to have nailed it finally (I think). Caveat emptor: this is an architectural bug that is expansive throughout the web application ecosystem, so it may not be easily viewed as a bug.

The DOM is supposed to be a document, not a business processor. But for quite a few years now, people have been using DOM events & event-handlers as business processors, instead of as mere documents. This has royally fucked up the separation of concerns between the DOM tree, Web Application APIs (Javascript), and Rendering (CSS, etc.).

It just so happens that usually, the only place to plant event listeners, and the only place to trigger events, is on DOM elements. So what happened is that in pursuit of writing event-driven business processes into code, people have been writing event-driven business processes into the DOM.

The data structure of a web application is NOT supposed to depend on a DOM tree. Therefore close-coupling between {data models in a web application} (read in 2019 as "stores"), and {specific node trees in a DOM} is an anti-pattern.

But isn't the DOM supposed to mediate such user-interface actions as receiving input from the user, and sending feedback to the user, you might ask? Yes, of course, these can be modelled as events, and the DOM provides us data structures pertaining to those events, as well as ways to operate on those structures (listeners).

But that does NOT mean that the DOM is also supposed to handle traffic control for events throughout an entire web application. A web application should have an eventable control centre which lies OUTSIDE the DOM. (That is, outside any light, shadow, or virtual DOM, in case it wasn't clear). We generally know how to do this on the server, since NodeJS lit the rage on this. But web applications are not always supposed to run on the server - often times we want a web application to run robustly on the client side, and to depend on servers only for federated data stores. So how do we go about writing web application CLIENTS that have EVENT-driven traffic control OUTSIDE the DOM?

With that in mind, I searched for implementations of event listeners outside the DOM, and was pointed to the Reactor pattern by this thread.

I look forward to examining it more closely, perhaps with your input.