6 ms·

I don't chain everything in JavaScript anymore

• slooonz 6mo ago
  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.
• tears-in-rain 6mo ago
  [flagged]
• prismatix 6mo ago
  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.
• plumbees 6mo ago
  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)
  • plumbees 6mo ago
    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.
    • shaftway 6mo ago
      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.
• joshstrange 6mo ago
  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".
  • nottorp 6mo ago
    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.
• mekoka 6mo ago
  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.
• efilife 6mo ago
  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
  • me_vinayakakv 6mo ago
    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.
    • Planktonne 6mo ago
      > 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.
      • me_vinayakakv 6mo ago
        Agree! That made me skim through the article till the end and come back to discussion after AI-detector kicked in.
  • mpawelski 6mo ago
    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.
• khelavastr 6mo ago
  Name return variables bro. This is a solution that people fixed 25 years ago with detailedReturnObjectNames.
  • jfengel 6mo ago
    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.
    • foobarian 6mo ago
      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.
      • jfengel 6mo ago
        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.
• t0mpr1c3 6mo ago
  The point of chaining is generally to avoid making intermediate objects.
  • recursivedoubts 6mo ago
    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?
    • azangru 6mo ago
      > the intermediate objects are still created Yeah; this is what the new iterator methods were intended to solve https://x.com/MozDevNet/status/2029527411424219254 https://x.com/MozDevNet/status/2029527411424219254
      • zamadatix 6mo ago
        Basically? // This type of usage creates intermediates array.map().filter() // But these would not? array.values().map().filter().toArray() array.values().reduce()
      • phpnode 6mo ago
        unfortunately iterators have their own set of overheads and it's not clear that these new methods are any faster for most use cases.
• takihito 6mo ago
  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.
• recursivedoubts 6mo ago
  a non-AI similar take: https://grugbrain.dev/#grug-on-expression-complexity https://grugbrain.dev/#grug-on-expression-complexity
  • k4rli 6mo ago
    Which part in OP article indicated AI? Probably is, but hard to tell exactly.
    • Planktonne 6mo ago
      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 https://en.wikipedia.org/wiki/I_know_it_when_I_see_it
    • pwdisswordfishs 6mo ago
      [dead]
• ramon156 6mo ago
  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.
• l5870uoo9y 6mo ago
  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`.
• jrimbault 6mo ago
  Note that for little while now lazy iterators have been available: - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Iterator https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... - Array.prototype.values https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/values https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... This addresses a few criticisms here, and the main criticisms I had.
• another-dave 6mo ago
  > 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
  • kakacik 6mo ago
    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.
  • HumblyTossed 6mo ago
    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.
• draw_down 6mo ago
  [dead]
• kalaksi 6mo ago
  > 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.
• bena 6mo ago
  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
• kubik369 6mo ago
  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.
• danfritz 6mo ago
  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
  • chuckadams 6mo ago
    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.
• rererereferred 6mo ago
  There was a pipeline operator proposal for javascript using `|>`. Whatever happened to that?
  • chuckadams 6mo ago
    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.
• __mharrison__ 6mo ago
  Folks need to learn how to debug chains. The juice of writing with intermediate variables is not worth the squeeze.
  • _ZeD_ 6mo ago
    I'll byte: how do you debug chains without intermediate values?
    • __mharrison__ 6mo ago
      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).
• eugenekolo 6mo ago
  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.
• po1nt 6mo ago
  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.
• chuckadams 6mo ago
  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.
• tantalor 6mo ago
  This seems to have very little, if anything to do with JavaScript. These claims could apply to any programming language.
• latexr 6mo ago
  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.
• jauntywundrkind 6mo ago
  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 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.