The counter argument would be wrong.

The advantage of the operator and the `pipe` helper over regular function composition is that you can emphasize the flow of data through a pipeline of functions.

The only advantage in readability I see here is that the operator is hard to mistake for anything else, it sticks out of the code, more than a seemingly regular function call. But this is not an advantage that justifies introducing the operator.

Other than that, UX and cognitive load is the same.

Pipes can indeed be fantastic! ;)

*

Apropos composition: why not add a composition operator while we're at it? Or we could define something like:

  const compose = (...args) => pipe(...args.reverse())
  

and then

  compose(square, increment, square, 2)
  

;)

For me there is also something more ineffable that's important here. A question of whether adding a new built-in operator fits within the general philosophy or some sort of "look & feel" of the language, or whatever. I think JavaScript seems to be quite conservative, when it comes to bringing in new operators. Perhaps that's a good thing. Maybe not. But so far, I remain unconvinced.

How would you add extra arguments to a function with your method?

You could just make the function, like square, accept arguments and then return a function that can be composed in that way.

That gives it a huge disadvantage over just using the pipe operator, particularly with standard functions:

  const pow = x => y => Math.pow(x, y);
  pipe(2, pow(5), square);

compared to just:

  2 |> Math.pow(5) |> square

The referenced operator proposal advocates the same solution[0] as @yladiz suggested here, so it's not clear to me where did you get this:

  2 |> Math.pow(5) |> square
  

from? This would mean the same thing as:

   Math.pow(5, 2) |> square

right? This seems like a pretty hairy thing to implement into the language. Also I don't think this syntax is very clear.

A more concise way of doing this with `pipe` would be:

  pipe(2, $ => Math.pow(5, $), square)
  

Compared to the operator:

  2 |> $ => Math.pow(5, $) |> square

So no disadvantage at all.

[0] https://github.com/tc39/proposal-pipeline-operator#user-cont...

Oops, you're right. I was confusing the proposal with how it works in Elixir.

I really like the partial application example from your source:

  let newScore = person.score
    |> double
    |> add(7, ?)
    |> boundScore(0, 100, ?);

Partial application is a separate stage 1 proposal but together with the pipe operator I really prefer this:

  let x = 2
    |> Math.pow(5, ?)
    |> square

to this:

  let x = pipe(2, $ => Math.pow(5, $), square)

How about this:

  let x = pipe(2
    , Math.pow(5, ?)
    , square
  )
  

;)

Sure but the proposed syntax is much cleaner and expressive imo.

Fuzzy words and your opinon, so can't exactly argue with that.

But here's a try ;)

I take it that the meaning behind the words you used is:

clean:

    no need for `pipe(` prefix and `)` postfix

expressive:

    can convey a pipeline in a distinctive and unique way
    (with a special operator as opposed to regular function)

Let me use the same words, but with different meaning, to say "the pipe function is much cleaner and expressive IMO".

The meaning would be:

clean:

    looks (is) the same as regular function application,
    no need for dirtying the syntax up with
    a special operator

    need to only press one extra key per operand/argument
    (,) as opposed to 3 (shift+|,>) ;)

expressive:

    can convey a pipeline just as well as the operator;
    it's a regular function, so it's first class,
    unlike the operator

    it's variadic, so you can combine it with
    spread operator syntax like:

      pipe(data, ...pipeline1, ...pipeline2)
      // where pipeline1 and pipeline2
      // are arrays of functions