I don't chain everything in JavaScript anymore | Hacker News Reader

I don't chain everything in JavaScript anymore

allthingssmitty.com

> 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

It's easier (at least for me), in a debugger, to hover over the intermediate variables in the bottom version and see what the result is.

One benefit of the more verbose lower example is, that when it fails somewhere you get a clear line where it failed so can focus already deeper. In chain, unless I am mistaken here (maybe mixing java and javascript so sorry if I am off), its just a general error somewhere in that chain.

Nothing earth-shattering, but who never had to debug something someone saw in production once and never again, then any additional useful info is weighted in gold.

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.

the intermediate objects are still created, they just aren't given names/saved to a specific memory location somewhere

do you mean like streaming APIs where intermediate data structures aren't created? Is that what javascript does w/map() etc?

> the intermediate objects are still created

Yeah; this is what the new iterator methods were intended to solve

https://x.com/MozDevNet/status/2029527411424219254

Basically?

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

unfortunately iterators have their own set of overheads and it's not clear that these new methods are any faster for most use cases.

> 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.

I'll byte: how do you debug chains without intermediate values?

Disclaimer: I wrote a book about pandas that is semi famous because it focuses on chaining. And it has a while chapter on debugging chains.

Debugging: use a debugger, create intermediate variables using .pipe (and side effects), logging, testing, writing your code clearly (use good naming).

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)

I guess I'm struggling because I also do like the IDEA of the unix commands being text that is piped around through commands so I do enjoy the concept of the purity of that mechanism.

This is the difference between a command (which is discarded after it's executed), and production code (which you probably want to keep around for a little bit).

But I'm in the same boat. I love the expressiveness of chaining a whole thing into a single call, but I have to break it apart for my own sanity.

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

Doing everything in one reduce step sounds to me like the opposite of "easy to reason about". Reduce is a powerful tool that everyone should know, but you don't always want to wield the most powerful tool, especially if you're after intermediate values like the OP is.

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

Yeah, nowadays I'm finding more and more of such things and not wanting to read the article further. Sometimes I feel we ignore some good pieces because of LLMification!

When I write, I now use LLMs as an alternative to Grammarly and explicitly instruct it to not to rewrite. Sometimes the choice of words are very intentional and LLMs dont "feel"/understand the emotional reason behind that.

> 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.

Agree! That made me skim through the article till the end and come back to discussion after AI-detector kicked in.

Yeah, and the content is not really thought provoking by any means.

I was surprised to see such obviously low quality slop here on HN.

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

Which part in OP article indicated AI? Probably is, but hard to tell exactly.

Staccato prose, subtitles like a sales pitch.

Mostly though, it's a combination of a thousand little things. There's no perfect bullet point list for 'this is AI', and if there was, AI would be able to hide it.

What humans are good at is seeing the uncanny valley in both images and prose. It's an old test [0] and we haven't managed to formalise it (or, as above, would even want to), but it's reliable for people with sufficient literacy.

[0] https://en.wikipedia.org/wiki/I_know_it_when_I_see_it

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".

Don't forget your humble ifs. Add the {} even if it's one line and the language makes the block optional. You'll thank yourself in 1 year when you come back to that piece of code.

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?

Death by endless committee, stuck in stage 2 until the heat death of the universe. Even PHP managed to get a pipe operator in the language before JS.

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.

1. The pipeline is simple to split or cut entirely, though. No reason to grow it into a monstrosity, but many reasons to not do it. This problem sounds similar to growing a function too much.

2. I agree in general when talking about more complex operations. Simple transformation and filtering rarely needs intermediate variables for readability or debugging. And the naming of result variable already describes the final collection.

3. Never had to deal with this kind of code but I haven't used Kotlin.

1. Yes, you hit the nail on the head. It basically requires people to be more cognisant of this. However, I think telling people to break stuff out into intermediary variables is much easier to argue for than whether the function is getting a bit too long.

2. Yes, easy filterings usually don't need to be broken down/named, but it really depends. At the very least, if the culture is to name intermediary values, you might accidentally get useful information from the variable names even if people weren't diligently writing explanatory why comments.

3. This isn't Kotlin related, it is just that if you do not have a language/codebase with branded types (or some type system property I don't know the name of), the type system might only infer the base primitives of the result, ending up with stuff like the type I mentioned.

Name return variables bro.

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

Can you elaborate on that? I'm not following. What makes return variables special?

I'd expect that much of the time, the return variable is closely linked to the name of the function. So closely linked that it risks being redundant.

Not JS but I like having explicit return var assignments because it's easier to break on and inspect. I don't know why tools don't make this easier.

Ah, yes, I've had that problem. With some debuggers I can place a breakpoint after the return, but it won't tell me the value on the stack to return. I can look up the stack and hope at some point I'll be able to get a handle on it (assignment to a variable, passed in as an argument, etc) but sometimes I can't.

I probably won't adopt this as a convention, just because most of the time when I have access to a debugger I'll also have access to the source code and handle it myself. But I'm going to keep it in mind, and perhaps get fed up at some point and decide to adopt the idea. Thanks.

Reply on news.ycombinator.com