Is functional programming in JS really worth it?

First off, there is nothing in FP that says you have to decompose every single operation to the greatest degree possible and make everything operate in a curied manner. This is simply stuff that functional purists want, but a lot of it actually doesn’t have much practical benefit to developers or users.

Composition is useful in a number of cases, but it becomes visibly less practical the smaller your functional units are. Same for the concept of pipelines.

As an easy example, the following two samples of Elixir code are functionally identical, but the second is far more readable for most people (the |> operator in Elixir takes the value on the left side and passes it as the first argument to the function on the right, evaluating left to right as it goes):

x = f(g(h(y)))

x = y |> f() |> g() |> h()

Of course, you could also do the same thing with temporary variables (and that would be the norm in many languages that have mutable data types), but that requires you as the developer to keep track of more things. And, again, this looks impractical to some because of how short the sequence is, but once you have a pipeline a dozen or more functions long, or all the parts of the pipeline take anonymous functions in addition to the starting argument, it makes things visibly less cleaner.

I'm in the camp that believes in balance.

Functional Programming can be very useful in some cases. That doesn't mean you should 100% buy in and become a purist, as there are always trade offs. Its undeniable that Functional Programming isn't new, can get complicated or confusing, and didn't catch on for a reason... 40 years ago.

I think its false belief that you have to 100% buy into functional programming to make it work and be useful for you. As you pointed out there are some very useful ways to leverage functional programming here and there.

So yes "beware the hype", always beware the hype, and focus more on the underlying content, and less on what people say about the underlying content ;D

FP doesn't mean you're not allowed to string two tokens together unless they're functions. :P You have to compare apples to apples. Let's take an array of words, transform it into an array of numbers (where each number is the number of letters in that word), filter out the numbers that are odd, add all the numbers together.

This is imperative:

let result = 0;
for (let word of words) {
  let length = word.length;
  if (length % 2 === 0) {
    result += length;
  }
}
return result;

This is functional:

return words
  .map(word => word.length)
  .filter(length => length % 2 === 0)
  .reduce((accum, current) => accum + current);

Technically that's OO, since we're using methods on the Array object, but this is fundamentally an FP-style operation: it's declarative, it doesn't mutate anything, and there's no control structures. You could write the same thing with pure, free functions in a pipe instead of the method chaining. Here's what it would look like with lodash/fp:

return flow(
  map(word => word.length),
  filter(length => length % 2 === 0),
  reduce((accum, current) => accum + current)
)(words);

Several points:

I wouldn't even know how I could justify writing code like this to my team members.

Code should be readable by the team. Think of how much time you spend learning FP concept. The same amount of time would need to spend each team member...

You can learn and practice FP (in personal projects), but I would not put it in shared code base unless the whole team is on board.

Second: it depends how you define FP, but if we would define FP as the style programming which avoids mutations and side effects. You would see that curried functions and combination is not a goal by itself it's just a tool to achieve the goal. So you can use them or not as long the main goal achieved.

Third: JS doesn't have good support for FP. It has some bits, which would make your code look like FP, but not always give you the benefit of FP.

There are a lot of built in functions, which will mutate objects, for example RegExp.prototype.exec() or Array.prototype.splice(). There are no immutable data structures, so you would need to use something like immer to take care of that (or use copy with spreds).

What comes at no cost in FP languages, like auto currying or combination, you would need to implement or use library for it, like, rambda.

You can as well try to learn FP in a language which was designed for it, for example, Elm.

What is "imperative" about those first two functions? They don't modify their arguments or count on some global state. They'll always return the same value given the same input.

I'm also on a journey to learn functional programming. For me it is worth it because it "fits better" with the way I want to write code and think about problems. Using concepts and patterns from functional programming I can solve a problem one function at a time, that's really powerful. Now, I personally don't go "full functional" with javascript because you can get to a point where applying a "functional pattern" doesn't feel natural, sometimes the best and fastest way to solve something is the good ol' procedural/imperative style.

I haven't done any serious projects with javascript but I did make an experiment in one of my side projects where I tried to use as many things from functional programming without it being awkward. I really liked the result.

Functional programming in JavaScript is optimal for production code e.g. when minified inside IIFE, because function name can be renamed. You cannot minify object property.

isOdd(x)

vs.

x.isOdd()

I've listened to a few talks and read a book or two about functional programming. I would hope it's not a surprise that there isn't really a single definition of FP.

The one thing, however, that I've never come across is that point-free (tacit programming) is somehow more functional. It's sometimes more declarative, sure.

Consider that method chaining in OO languages is a form of tacit programming as well:

oby = oby'.addValue(5)
  .setPrecident(true)
  .prefixWith("hello");

This isn't more functional than the equivalent:

oby1 = oby'.addValue(5)
oby2 = oby1.setPrecident(true)
oby = oby2.prefixWith("hello")

You can see how a tacit style is sometimes easier to read, but it isn't more functional

Sometimes, however, it can be more efficient. These two functions are almost the same:

const thing1 = increment;
const thing2 = n =>  increment(n);

thing1 and thing2 are both functions that increment their input. thing2, however, needlessly wraps this in a lambda. So thing2 performs ever so slightly worse as it must push and pop from the call stack one extra time.

Every code snippet in this article is functional. The only difference between your imperative and your functional examples is that the functional examples are convoluted.

isEven and isOdd are honestly such small tasks that it's hard to implement them in an imperative way. After all, imperative programming is about having a sequence of statements that have side effects, such as mutating variables.