That's a baffling definition of IO and IO loops. It sounds like you think bidirectional IO is an IO loop, as opposed to unidirectional IO (which . . . does that even exist outside of "write bytes here" shared memory constructs? Even UDP write operations get data back from the kernel), but you also classify a socket, which is typically bidirectional, as just "IO", so I'm not quite sure what to make of that. It sort of sounds like you're talking about asynchronous IO, which is often coupled with event loops (which may or may not be IO loops unless you define time-based conditions as IO) in practice, but doesn't fundamentally have anything to do with them. Is that what you mean?

When you talk about an event emitter, what kind of code structures are you referring to? An EventEmitter a la Node.js is a pretty decent separation of IO and data, though not perfect: something external (perhaps an event loop) triggers subscribed code based on IO, but your code is given only data (payload) to process. Is your beef that 'someThing.onEvent(eventType, e => whatever)' is more 'OOP' than 'bindEvent(someThing.eventType, e => whatever)' is 'functional'? If so, how or why?

In general, it sounds like you might be referring to typical JS asynchronous IO (callbacks/promises/async-await and whatnot) when you talk about IO loops. But I can't for the life of me figure out what those things have to do with OOP vs functional programming, nor why using those structures requires you to store state on a "widget".

> Look at where events come from and where they are sent. How do you associate the action of button A with the data representing button A?

I can say 'button.onClick(() => { button.clicked = true })' just as easily as I can chain every computation which would happen as a result of 'button.clicked' being true onto the event instead. The former is more OOP, colloquially, than the latter, but is definitely not inherent to UI programming: tons of popular patterns and frameworks exist whose primary goal is to remove the coupling between state and UI appearance.

> In functional you have a linked list of composed immutable functions with an input on the head and an output on the tail. Nothing is mutated.

This has nothing to do with functional programming, or a functional style. Immutable data exists as a very common pattern in both colloquially-FP and colloquially-OOP languages, and so does mutable data.

At the point where you start talking about linked lists, I begin to think that you're misunderstanding or misusing some fundamental term we're discussing (Mutability? IO? Functional? Object? I'm not sure): a LL is a data structure (which is mutated by adding/removing elements, traditionally), and has absolutely nothing to do with programming style or paradigm.

> A UI widget cannot just be a function. A widget in-itself is data, the structure, the display, the color ... etc.

No, a data object can contain those things, but in higher-level UI programming, the data object is very very rarely the "widget" itself; it's just data that is supplied to the renderer (the API of which, in web UIs, is the DOM), and the renderer generates the UI based on that.

You can do that in a tightly coupled way and store all your state in the DOM, or you can use any one of many powerful systems that allow you to separate those and perform operations only on data, which can be applied to the external UI state outside of your code. React is a good example of this.

> HTML is basically pure data.

I think you're confused about the difference between HTML (text, can be generated and passed around by code) and the DOM (the API to what is being rendered by the browser). HTML is data, sure.

> You can still keep it functional if you have a function dynamically generate HTML based on a set of parameters (IO without a loop).

That's what event listeners and callbacks are. Whether or not you're dynamically generating HTML, or whether code is mutating it after it's loaded into the DOM, has nothing to do with functional-or-not. Code doesn't stop being 'functional' as soon as its goal is to alter the state of or handle input from some external thing, whether that's a DOM node or a traffic light.