I don't chain everything in JavaScript anymore

Uh huh.

I thought this would have some decent insight as to memory usage or something.

Nope. It's just clinically stupid.

His first example is pretty much the same either way. I would say the "better" way is a little more involved to read. But it's nothing either way.

His second example makes unnecessary chains. He filters, then maps. When he could just use find and get the name like he does in the "steps" version.

Maybe we need fewerthingssmitty

I whole-heartedly sympathise with the problem author is trying to describe. He does not introduce it very well, but if you read through the whole thing, you should be able to get the gist of it.

For me, the problems with chaining from the point of mostly maintaining existing software are:

1. Harder to impossible to reason about.

As the author alludes to, 1-2 chains are fine, but it starts getting impossible when you get into a territory where you have a longer chain which has a deeper call tree. This happens over time where you start with a smaller chain and people start lengthening it, adding helper functions which grow into large call trees, etc. This makes it so that you have sort of a blackbox pipeline that is, at the very least, annoying and time-consuming to inspect.

2. Harder to debug

Author tries to mention this but he seems to fail/stop short of pointing out what is wrong with the example he provides. For me, I work with Kotlin. In Kotlin, you cannot put a breakpoint in the middle of the chain! As far as I know, you can only put a breakpoint inside of the chained function calls and do step-into/step-over and such, but you cannot put a breakpoint in-between chain function calls. This means that debugger is basically useless if your codebase looks as described in my previous point. The solution is to write a bit more code at the start, naming each variable. This makes it much easier to debug the code/logic (because you can put a breakpoint on the specific variable/step you are interested in) and, more importantly, to understand, because you explain the steps with the variable names and optionally also with comments.

3. Related problem - return chaining

Another issue I have in codebases I inherited is what I would describe as return chaining. It is what happens when you have code which returns a function call and the called function does the same thing and so on and so on. Minimalistic example:

  foo() {
     return x
        .map()
  }


  baz() {
     return foo()
        .map()
  }

  fbaz() {
      return baz()
        .map()
  }

This way, there is usually no good place to inspect the values and it is hard to reason about what even is the return type/value. Yes, the type system can take it, but good luck figuring out what is Map,List>. Do this instead even though it looks "less clean"/uses a supposedly useless variable:

  foo() {
     const helpfulName = x.map()
     
     return helpfulName
  }


  baz() {
     const anotherHelpfulName = foo.map()
     
     return anotherHelpfulName
  }

  fbaz() {
      const superHelpfulName = baz.map()
      
      return superHelpfulName
  }

In summary: please, for the love of all that is holy, resist the urge to write function chains, always store meaningful intermediary values in named variables with "why" comments in relevant places and do so especially with return values.

There was a pipeline operator proposal for javascript using `|>`. Whatever happened to that?

Folks need to learn how to debug chains. The juice of writing with intermediate variables is not worth the squeeze.

> Sometimes I feel we ignore some good pieces because of LLMification!

As a heuristic for attention, "does the claimed author care about, understand, or even know what they're writing about?" is not a bad start.