This is my experience as well. I had a co-worker that really pushed for FP in JavScript using Ramda.js. the principles were appealing, but because JavaScript doesn't have native syntax for many of the principles like pattern matching, you end up with hard to read code that's a bunch of nested arrays or chains wrapped in helper functions like "compose([fn1, fn2])(data)".
I later tried to learn F# and while the syntax was foreign, it turned out that it was MUCH easier to write FP code because the language had native operators for composition, etc. The code was also much easier to read.
I think it would be great if JavaScript got some FP syntax natively (see the pattern matching proposal). But hacking functional principals using arrays and helper functions just leads to hard to read code, especially for people not familiar with the specific FP library you chose to use.
I'm actually thinking about putting together a series of posts on the topic of "Full-stack ClojureScript for JavaScript developers". I've heard ClojureScript described (from a functional programming standpoint) as "JavaScript, but without the stupid parts", as it basically gives you the benefits of Ramda.js + Immutable.js without the headaches of making those libraries play nicely with native JavaScript. It also doesn't veer too far into the theoretical (monads, category theory, etc) so it would make for an easier transition when coming from JavaScript (you can even throw exceptions if you want).
I became a Clojure fan-boy over the course of the last year but one issue that seems to keep popping up when I discuss it with my JavaScript/Node.js co-workers is "Clojure runs on the JVM? Not interested".
Setting aside the technical validity of that opinion (JVM vs. Node.js), it made me wonder if there might be more interest in Clojure from the JavaScript world if they knew they could use ClojureScript for both the front-end and the back-end (on Node.js).
I think I'm like your co-workers, I'm really interested in Clojure, but admittably have that (probably unreasonable) JVM aversion. Do you mind sharing why I shouldn't?
The JVM is an excellent general purpose, multi-threaded runtime, with a large ecosystem of open source libraries, and its well suited to many types of "back-end" workloads, which is why it was the initial target for Clojure back in 2006/2007. Clojure's great interop with its host platform made it easy for people to get up and running while leveraging all the existing Java libraries they were used to.
The JVM is still a great choice for all those reasons, but its a little heavier than Node.js which specializes in IO bound use cases (i.e. the back-end-for-front-ends that sit between the browser and the heavyweight back-end systems). Node.js is also probably better suited for smaller services, lambdas, and other light-weight scenarios (IOT?).
I'm interested in promoting a full-stack approach to ClojureScript because the JavaScript/Node.js ecosystem is everything that the Java ecosystem was 15 years ago. It has lots of developers, lots of libraries, and a "bad" language. And by sticking with Node.js, its one less hurdle for JavaScript developers to clear when learning ClojureScript. They still get to use all the same libraries they did before (via ClojureScript's great interop), and the runtime characteristics they are used to. Plus, if they then decide to start looking at Clojure on the JVM in the future, they will have already learned the language.
Do you have a link to the pattern matching proposal? IMO if you added pattern matching and made everything (blocks, if-else, switch statements, etc) expressions then JavaScript would be pretty decent for writing in a functional style.
I have written non trivial projects with ramda and I like it a lot. You have to use your judgement with readability. Some of the advanced functions are a little hard to grok at first, but most of the library is pretty straight forward.
I later tried to learn F# and while the syntax was foreign, it turned out that it was MUCH easier to write FP code because the language had native operators for composition, etc. The code was also much easier to read.
I think it would be great if JavaScript got some FP syntax natively (see the pattern matching proposal). But hacking functional principals using arrays and helper functions just leads to hard to read code, especially for people not familiar with the specific FP library you chose to use.