Breaking Chains with Pipelines in Modern JavaScript | Hacker News Reader

Breaking Chains with Pipelines in Modern JavaScript

wix.engineering

25 pointsfagnerbrack15 comments

Maybe it's just me, but I don't see the purpose of a pipeline operator - at least in JS.

From a cognitive perspective, it doesn't make code more readable or easier to understand.

From a practical perspective, why? What can't we do with it that isn't aesthetic?

Edit: Okay, after reading through the article again, I get it. I've had issues with eager loading in Node AND I will say the pipeline is easier to understand than simply using generators. Good article.

A simple example would be mixing map/reduce stuff on arrays with other non-built-in utility functions that take arrays without having to break the logical flow.

For a very simple example, manipulating and summing an array of values:

    import { range, sum } from 'ramda';

    range(0, 6)
      |> x => x.map(i => i * i)
      |> sum

Compare to:

    import { range, sum } from 'ramda';

    sum(
      range(0, 6)
        .map(i => i * i)
    )

...and then add three or four other non-builtin methods in between map steps and consider the resulting readability.

I mean, I think one of the big arguments against a pipeline operator is that you can easily roll your own with

  const pipe = (...fxs) => x => fxs.reduce((v, f) => f(v), x);

If you're going to pull in ramda for example, they have their own pipe, and a map function that takes (predicate, array) as curried arguments, to aid with composition import { map, pipe, range, sum } from 'ramda';

    pipe(
      range,
      map(i => i * i),
      sum
    )(0, 6)

I haven't messed with HN formatting before, so I hope that turns out right. My team uses Ramda and pipes regularly in our Node code, and its absolutely wonderful

I really wish we could just get a pipeline operator past stage 1. It seems like such a simple idea philosophically but apparently the big players can't agree on any of the exact details.

> Fortunately, a much better syntax for this type of expressions is being introduced by ECMAScript, known as the pipeline operator.

This is "Stage 1: Strawman Proposal." It's not exactly accurate to say the operator is being introduced "by ECMAScript", more like "it's being proposed for addition to the ECMAScript specification."

I would have preferred .pipe, .partial and .partialRight functions in the std library instead of adding more syntax sugar.

Since when does "modern" mean not-yet-standardized?

perhaps it should be called "post-modern"?

https://sequoia.makes.software/what-is-javascript-part-1-the... agree

Huh, I'd never seen a pipe method with the # as the placeholder before. That seems like a pretty nice way to make it flexible.

Clojure has a similar thing, where % is used as a placeholder in threading, which is similar https://clojure.org/guides/threading_macros

Personally, I'd rather see it go through with no placeholder at all so it can just happen without people arguing over it forever, and then have a placeholder added in a future proposal.

RamdaJS may interest you if you like pipes

https://ramdajs.com/

For anyone looking at picking up Ramda, the docs at ramdajs.com are great API docs, but don't tell you a thing about how to actually use lenses, transducers, and point free data last functions with pipes. Randy Coulman has a great list of guides on how to actually use Ramda on his blog[1]. Start at the bottom with the introduction and work your way up.

https://randycoulman.com/blog/categories/thinking-in-ramda/

Reply on news.ycombinator.com