This is of course a silly but valid criticism of a post claiming FP is better than OOP in every situation. As others have pointed out, there are functional GUI frameworks, though of course something state-heavy is going to be more naturally modeled with OOP in some cases.

But that is all beside the point- OP specifically did not claim FP was always better, just that they found it more natural. That personal and subjective experience (which I share) is utterly orthogonal to the relative maturity of GUI libraries! The fact is, most GUI frameworks are OO, and the ones I learned were all OO. And I hated them! I am not a person who enjoys making GUIs, and that's in large part because I am not a person who enjoys OOP. When I learned my first functional language, it felt like a breath of fresh air. While I was a perfectly serviceable Java and Python programmer, Haskell just made sense immediately. That doesn't make Haskell a better language in absolute terms, but it was much better for me.

Now that I've worked with functional languages, I find I actually don't mind imperative languages at all. I don't really need 100% of the bells and whistles to write composition focused code that meshes with my brain, especially since just a hint of state here or there can free you up to do the rest of it statelessly. And now I find that as I build interfaces with LiveView or Vue that I actually do enjoy making GUIs- even if there is a little state here or there.

People, and this might come as a shock, are sometimes different from each other. And sometimes their talents don't match up perfectly with whatever task you feel is important in the moment. There's lots of programming which isn't as state-heavy as a GUI, just as there's lots of programming more state heavy than a data processing pipeline.

Off the top of my head:

  * React
  * Elm
  * Halogen
  * Phoenix
  * Phoenix LiveView
  * Re-frame
  * Reagent

React moved away from OOP quite a while ago. It's mostly pure functions and closures that return what are functionally records.

When the JS tuple/record proposal is finally implemented, I suspect they go even farther in that direction.

Of course, you could argue that closures are simply objects with one method (or that objects are a poor man's closures), but that's a rather pedantic line of discussion.

React is written in JavaScript, a OOP language with prototype inheritance similar to SELF, it doesn't get more OOP than that.

Take anything that has object semantics on the JavaScript VM out of React source code, and it will be reduced to almost nothing.

The fact that JS has OOP doesn't mean your code relies on those OOP features in any meaningful way and MOST modern code does not.

JavaScript functions and basic data types have member functions and object prototypes, so...

It is like writing React in Smalltalk and arguing that because the code uses code blocks it isn't OOP.

Swiftui

Plenty of Swift classes and method dispatch going on there.

Jetpack Compose (Android)

Plenty of Kotlin classes and method dispatch going on there.

Aside from the all the FP-style GUI frameworks others have listed, it's also worth noting video game development adopting "data oriented design" [0], rather than OOP (usually in C++).

[0] https://www.youtube.com/watch?v=rX0ItVEVjHc

In this case FP is even worse (you need to copie information to use it), I don't feel this is a case of which is about paradigms but more of make paradigm that push the limits of the hardware

A smart enough compiler will eliminate 90% of unnecessary copying and things like linear/affine types will eliminate the rest

I wonder if dearimgui would count or if it's just imperative

I would put it more on the declarative side of things than functional or imperative. It does feel like a better fit to imperative programs though where execution is moving through the code as opposed to functional programming where expressions evaluate to results.