You certainly can create user interfaces without mixing them. An example is a fad in the js world called https://en.wikipedia.org/wiki/Unobtrusive_JavaScript that was popular for a while. I also questioned if event elements and visual elements should be mixed and I think that's generally the most direct approach. User interfaces should be a two-way communication between a user and a program. Events as inputs to the program and graphics (or otherwise) as outputs from the program to the user. Therefore, a User Interface needs to specify both. However, why not specify them completely separately? The reason the two are mixed is that it's the most direct way to relate the handling of inputs to the graphics shown to the user. It's rare (maybe impossible) for the event handling of a good user interface to not be related to the graphics displayed to the user. There may be use cases where you'd like to implement the graphics and visuals separately, but I've found that it's usually more convenient for the code to be colocated. One of the issues with traditional event handling is that child components often don't have enough info to know what to do when an event happens, but I think functional bubbling does a good job addressing that issue. Child elements can return intents with the information they do know and parent elements can supplement or augment those intents with any additional relevant issue.

Thanks! I hadn't heard of unobtrusive js. Right, it's most obvious to think that it's colocated for convenience. The not so obvious point is that the parent has more context and can translate the child element away from the domain of text and rectangles and towards the application domain. I can see it but it's not intuitive to me that it must be that way. e.g. I don't know if it's inherent to the view hierarchy that it provides the domain translation. Maybe I can build intuition for that. The "part" is less capable than the "whole" that it's composed into. So, there's more domain stuff happening at the higher level. And then, if I accept that I have the hierarchy for domain translation and I need to translate the domain of the events from a low level "button clicked" to a higher level "todo item added" then it should make sense that the event handling is attached to the view hierarchy. Thanks again!

I think layers are overrated, the ideal lispy code IMO allows you to write background plumbing until you write your actual "business logic" all together succintly in one place, across all of the concerns

and writing all together in one file doesn't actually mean "coupled", we're complecting "coupled" with "colocated" then, if it's a globally accessible pure function then it has the benefits of decoupling no matter where that function is physically written

just my opinionated two cents

also influenced by speaking to the HyperFiddle author