[PaulHoule]

Some things are easy to express as functions (compilers). Other things aren't (user interfaces).

Even when immutable data is easy and is good from a software design perspective it is often a terrible choice from a performance perspective. Advocates say the performance loss is just a factor of two in many cases but that's why FORTRAN survived so long against C, why people are developing Rust when Java is available, etc.

[horsawlarway]

I don't disagree with you at all.

There's a reason no on is writing modern games in functional languages, and that reason is performance.

But that said - At least for me - the major attraction of React was that it really concentrated on making ui related code pure. Give a component the same props, and you get the same DOM.

That's a really powerful concept for reducing bugs, easing testing, and giving you composable components.

It is not a performance improvement.

I think hooks really hollowed out the value proposition here. Because class based components were more painful, I used to see a lot of care and thought put into consolidating the logic that generated props into a single class based component (consolidating state). That component would then mostly pass down props to pure components.

Hooks make it easy to just throw state into any old component - which is nice in some sense, but like I said - it hollows out the value proposition of having pure components.

Good teams will still try to write mostly pure components, but many folks will just liberally scatter hooks into their code, creating code that becomes increasingly hard to reason about.

[jokethrowaway]

That reason is not performance but familiarity and ecosystem. A trendy way in gaming to build games is to use ECS which is FP and there are very performant framework to do ECS.

[horsawlarway]

I would argue (pretty hard) that the reason is actually performance.

The ecosystem matured around C-style procedural language concepts because naive functional implementations simply weren't fast enough (and were often much more difficult to work with).

Yes - some companies do leverage FP concepts for development, but they're usually heavily modified for that specific purpose (ex: GOAL at naughty dog, ECS for Unity)

And even then... ECS is "vaguely" functional at best. The entities are mutable, and the logic in the systems is directly modifying those mutable entities. I appreciate that the logic is applied consistently, and I think there's value there that comes from FP - but it's very much not classic FP.