
Breaking Chains with Pipelines in Modern JavaScript - fagnerbrack
https://www.wix.engineering/post/breaking-chains-with-pipelines-in-modern-javascript
======
dvdhnt
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.

~~~
crooked-v
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.

~~~
MFogleman
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

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

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

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

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

~~~
sequoia
[https://sequoia.makes.software/what-is-javascript-
part-1-the...](https://sequoia.makes.software/what-is-javascript-part-1-the-
problem/) agree

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

~~~
sequoia
Clojure has a similar thing, where % is used as a placeholder in threading,
which is similar
[https://clojure.org/guides/threading_macros](https://clojure.org/guides/threading_macros)

------
archarios
RamdaJS may interest you if you like pipes

~~~
MFogleman
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/](https://randycoulman.com/blog/categories/thinking-in-ramda/)

