> Chaining nudges you toward “process everything,” even when that’s not what you meant to do.

It feels pretty clear that the chains in that example (filter/map) are meant for operating on collections. And that if you're searching for a single item then chaining isn't the way to go?

Personally, if I knew I wanted only a single item I wouldn't feel more "nudged" towards appending a [0] on the end of a long chain rather than doing a refactor to the find().

As to:

    data
      .transform()
      .normalize()
      .validate()
      .save();

here the problem isn't that you've done method chaining, it's that you've named your functions with terse names that you're going to forget what they do later on e.g. a generic "normalise" vs a "toLowerCase()" or whatever.

As apples-to-apples unchained equivalent isn't really any better

    const transformedData = transform(data);
    const normalisedData = normalise(transformedData);
    const validatedData = validate(normlisedData);
    save(validatedData);

Is not more readable or understandable

Note that for little while now lazy iterators have been available:

- https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

- Array.prototype.values https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

This addresses a few criticisms here, and the main criticisms I had.

The point of chaining is generally to avoid making intermediate objects.

  // This type of usage creates intermediates
  array.map().filter()
  // But these would not?
  array.values().map().filter().toArray()
  array.values().reduce()

> Yeah, it’s more lines. But each step is just sitting there. No decoding required.

I actually think the first code block is easier to read. It's a familiar (to me) and simple pattern that is quick to read. I don't get how it would require more "decoding" than the second example which is more disjointed and needs more "parsing" for such a trivial case. Maybe it's about what you're used to?

I agree there are downsides to chaining. With more complex operations it can complicate debugging, and readability can suffer, so chaining is not a good fit there.

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

Ageeed. The chained style is Points-free or tacit (never heard anyone use that term in the wild) programming. https://en.wikipedia.org/wiki/Tacit_programming

My opion here but: generally not a fan. Explicitness is a virtue. That itself can go overboard too!

In the olden days the chained syntax was also worryingly low performance: ideally you want to iterate only as many times as you have to, doing as much work per pass as you can rather than spreading it out across passes. The example code also creates intermediate arrays, versus working on place: not always possible but over allocating was another "are you trying to make this page look jank" trigger. The chained syntax prevents you from dealing with either, albeit iteration helpers somewhat ameliorate this.

Perl was very fun to write because there are so many predefined variables that would automatically be written to and read from. It allowed for imperative-ish code that still was incredibly tacit. All the data flow was implicit. Fun to write, incredibly hard to visualize.

I do wish we saw IDEs that made data flow analysis more visible. Overlay the source code with the compiler's sea of nodes, show the us the graph of compute that actually constitutes a section. I think we could be augmenting ourselves to do much more with implicit styles, to get the visibility of our code "for free", and at an even more explicit visually clear way than using lots of intermediate variables. Oh to dream.

The whole point of composable things like chains is that it's trivial to split them out into intermediate variables if you like. Or into other functions -- which JS's syntax makes slightly more annoying, but you can still depend on the semantics not changing from being moved around.

So if you like intermediate variables, great. I like them too. I also like having the option of chaining where it's necessary or just more expressive. Writing composable APIs means everyone wins.

Not trying to sound snarky, but this is just part of transitioning from a junior/mid to a more senior developer: realizing that code readability matters more than terse-ness.

What a high-level boring list of examples. Why not have one complex example that clearly shows your "take". (Quotations, because these "I stopped doing X, and now doing Y" posts are stupid. They're also easier to write now with LLM's.)

I'm sure there's a case to be made for either, this post just doesn't do it.

I agree that debugging these pipelines are a nightmare sometimes. It's something that frustrates me sometimes because even though in OOP it won't be terse the action would be clearer. OOP can at times also introduce less cognitive load as well. I wonder if the issue is the mixing of paradigms. Although I don't think everything should follow purity boundaries: functional must always be functional and OOP languages should just be OOP but perhaps the mixture of doing functional programming in a OOP paradigm introduces unintended quirks that are cognitively taxing when bugs occur. (I've written 10 drafts and I'm not sure what I want to say so I'm going to just land it here and see what happens)

The arguments for “process everything” don’t pass mustard, you’re not comparing the same thing.

> Chaining nudges you toward “process everything,” even when that’s not what you meant to do.

  const firstActiveUser = users
    .filter(user => user.active)
    .map(user => user.name)[0];

> This filters the entire array, maps the result, and then grabs one item.

> When what you actually wanted was:

  const user = users.find(user => user.active);
  const name = user?.name;

Then if that’s what you wanted, do that!

  const name = users.find(user => user.active)?.name

The fact that you processed everything in the first example was entirely your choice, it has nothing to do with chaining.

I can only say: learn how to use reduce and you never loop twice through a list of items or objects.

To me reduce is very easy to reason about and makes it super easy to properly filter, combine, extract values without ending with filters on filters on maps and maps

Generally I agree with the sentiment, for one major reason: debugability/dev loops.

Inevitably you're going to end up having to debug that each of those steps is correct, for that you'll find it a lot easier to break it out.. and the next person who has to do it will as well.

I do think the example is somewhat loaded though, rename "result" to "top5ActiveUserNames" would do a lot there.

I read two paragraphs of this and was already sure this article is AI generated. Read more, and "This isn’t just about..." there we go

I prefer chaining. Less code usually means more readability. I don't want to save intermediate variable if I don't need it.

const filteredUsers = users.filter();

Why create a variable if we use it on a single place anyway. Feels redundant like prefixing "I" in interface names.

a non-AI similar take:

https://grugbrain.dev/#grug-on-expression-complexity

This is what tends to happen to code when your focus starts to shift away from how expediently you can write it and closer to how readable/maintainable it really is.

When I see a magnificent series of functions, I feel a strange, indescribable feeling. However, it's difficult to feel the desire to actively engage with them.

Agreed, while chaining can look very pretty, it's a pain to re-parse and a pain to modify.

It's the same reason I don't like this style of function:

    .map(var => var.toUpperCase())

Sure, it's great today but but I want to debug it I need to add `{}` in and/or if I need to add a second operations I need to add the curly braces as well. That's I prefer explicit:

    .map((var) => {
        return var.toUpperCase();
    })

Since it's much easier to drop in a debug line or similar without re-writing surrounding code. It also makes the git diff nicer in the future when you decided to do another operation within the `.map()` call.

I've asked many people to re-write perfectly functioning code for this same reason. "Yes, I know you can do it all in 1 line but let's create variables for each step so the code is self-documenting".

One of the hardest problem in programming is naming your variables correctly.

I love chaining because it reduce the number of occurrences of that problem.

This seems to have very little, if anything to do with JavaScript. These claims could apply to any programming language.

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

Kinda feels like a code smell having to optimize your code this way. Normally, data state would be abstracted away in a data store (e.g., Redux), and then specific sub-selections are pulled out using pure functions, e.g., `getActiveUserNames`, `getActiveUsers`, `getTop5ActiveUsers`.

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<Map<String,String>,List<String>>. 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.

Name return variables bro.

This is a solution that people fixed 25 years ago with detailedReturnObjectNames.