This reminds me of a blog post (about currying specifically) from an ardent FP proponent that I picked up on HN not long ago, where he back-pedals (his own word) from a much-shared pro-currying in JS article:

https://hughfdjackson.com/javascript/does-curry-help/?utm_so...

On a personal note, immutability is fine, but doing it in Javascript comes at a cost and it always feels like I'm fighting the system (have to deep-copy objects and possibly even `Object.freeze()` objects, space-saving write-on-copy needs to be done by myself, no pattern-matching). So I only do it when I'm sure it is useful. Similar with some other FP concepts that feel natural in "real" FP languages.

Also, very few of the functions that cause me any headaches benefit from being pure (in a way that would help me), because my problem is with the consistency and state of the data in (shared) storage. I rarely have issues within the app itself, so "purity" there does not help me all that much in my very I/O heavy applications. It seems much more suited for data processing.