Seems like a weird thing to miss for someone who ostensibly prefers functional programming.

For example, people here will talk about `function User() {}` like it's the pinnacle of amazing abstraction. Because it has the word "function" in it or something.

There's nothing functional about that to me. Mutating the prototype and dealing with the implicit `this` variable in your functions is about as far away from functional programming as you can get.

Meanwhile Javascript just gets more and more functional, from the mindshare of higher order functions/components gaining traction to the @decorator transformation to the Promise 'monad'. It just gets better and better.

I have a hard time taking anyone seriously who doesn't recognize the pain that `class` solved in the ecosystem whether you personally decide to use it or not. People have been writing OOP code in Javascript since day one, just with some of the worst idiosyncrasies of all OOP languages.

People also write tons of bad functional code with JS. It gets worse and worse the more that people keep following this cargo cult of HOCs and functional programming. The obsession with using HOCs for passing a simple variable around is particularly absurd. Importing objects with methods (or even just a namespace with functions) is way, way cleaner than importing every function seperately.

Which stable and widely used GUI kit has ever been done well with functional programming? Until one exists, I can’t really take anybody who pushes functional programming for GUIs very seriously.

Functional programming just isn’t that good for complex domains. OOP is way better for GUIs.

ReasonML and ReasonReact agree with you: instead of HOCs, they prefer using standard functions, explicit “self”, and just passing things down through props. It’s quite a breath of fresh air really.

I suppose it isn't really a GUI but it does manage them.

http://xmonad.org/

At the moment, React does not yet have support for stateful functional components. It's something they've said they would _like_ to research and implement down the road, but right now, component state and lifecycle methods requires class components.

Or the use of something like recompose[1]'s `lifecycle` function[2].

1: https://github.com/acdlite/recompose

2: https://github.com/acdlite/recompose/blob/8c4ac2e4/docs/API....

Yeah, although that itself is implemented internally using an ES6 class:

https://github.com/acdlite/recompose/blob/8c4ac2e4a4cd8d60c8...