It‘s probably more like a Venn diagram with some overlap: X%+Y%+Z%, where Y% is the overlap between pipe operator and call-this. A lot of people have expressed interest in the pipe operator but not call-this over the years, even disregarding code-shaking as a motivation. I don’t quite think pipe-attracted people are a subset of call-this-attracted people. With that said, it’s true that we have not, to my knowledge, pitted them head-to-head in front of the community.

Well, actually, I think prior State of JS surveys have maybe asked developers about both proposals when assessing their interest in various TC39 proposals.
I’d need to double-check the prior years’ results…but I’m not really looking forward to doing so. It’s a good resource, but I find the State of JS websites difficult to navigate…

The point that Elixir pipes (but not F# pipes or Hack pipes) would support autocompletion on the first argument is intriguing. I wonder if autocompletion would have changed Daniel Ehrenberg’s decision to use F# pipes instead of Elixir pipes, back in 2017 (nearly a decade ago…).

Though I don’t know if I really want to wade through that whole pipe-style bikeshedding ordeal again. Weren’t quite a few people against promoting the zeroth argument to be special, even with PFA syntax?
And then there were the engine concerns with PFA syntax and optimizability of observable stack traces, etc.

I think we dismissed Elixir without really discussing its merits originally. There are definitely delegates that dislike the special first arg behavior, but there are also those that dislike this binding behavior too.

Re PFA and optimizing, I don't think this will be a concern the way it is with F#. Using PFA directly within a pipeline is optimizable, but we've only talked about PFA with F# and F# promotes any type of closure-returning function call.

Using the pipe readme’s example from node/deps/npm/lib/unpublish.js:

…I’m trying this again; Element’s message editing is so unreliable. From inside NPM’s code:

// Status quo:
const json = await npmFetch.json(
  npa(pkgs[0]).escapedName,
  opts,
);
// With Hack pipes
const json = pkgs[0]
|> npa(##).escapedName
|> await npmFetch.json(##, opts);
// With Elixir pipes,
// assuming that it supports a `|> await memberExpression(arg0)` form:
const json = (pkgs[0] |> npa()).escapedName
|> await npmFetch.json(opts);

Nit: we could support tacit pkgs[0] |> npa.

But yes, running arbitrary expressions is a little more difficult, and likely pushes some to do getEsapedName helpers or similar.

And await/yield could be handled as either special behavior inline, or a postfix |> await |> … so we don't redefine the expression inline.

That was from me trying Rx pipelines. You'd do x |> foo(a, b), which means you wrote a ton of code before we could figure out what you're doing.

Even with x |> foo(?), you still need to write foo( before we can figure out where you're placing the arg and how filter the possible set of functions.

There's also the potential for confusion by not supplying a first-arg when pipeline is involved, i.e.:

map(ar, x => x + 1)
// vs
ar |> map(x => x +1)

as these two calls to the same function could potentially live side-by-side in the same file.

The upside of PFA is that it kept that intuition as to argument placement. The argument didn't just disappear because I'm using |>:

const mapped = map(ar, x => x + 1);
// vs
const mapper = map(?, x => x + 1);
const mapped = mapper(ar);
// vs
const mapped = ar |> map(?, x => x + 1);

All three styles could be used interchangeably in the same file without confusing users as to argument order.

Ramda essentially avoids this because Ramda functions curry, so they set the expectation that partial application results in a bound function:

add(1, 2); // 3
add(1)(2); // 3
add()(1)(2); // 3

Each of these produces the same result, so it builds an intuition for the developer as to how arguments are applied.

It’s true that autocompletion engines could use a zeroth-argument-is-probably-the-principle-type heuristic on F# pipes, switching to the next argument’s type. With F# pipes and PFA syntax, as soon as I type x |>, my editor’s autocompletion engine could assume that I’m going to type x |> f(? or something similar, and it could show completions for standalone functions that expect x’s type at their zeroth parameters (followed by functions that expected x’s type at their first parameters, then second parameters, etc.). Just as a heuristic.

…And this would be true even for Hack pipes, too, wouldn’t it? If I type x |>, and we were using Hack pipes, the engine could also use the same heuristic. It could show functions that expect x’s type at their zeroth parameters (and then first, second, etc.). So, actually, Justin, I might have changed my mind again thanks to Ron, haha. I think Hack pipes probably are fine for autocompletion.

Sure, if you are the author of foo and don't mind the overhead of returning a closure, then maybe x |> foo(a, b, c) seems like a win. Performance wise, it isn't.
PFA gives you the option to produce a function and allows you to use existing functions that were not designed for currying. F#-style support for tacit functions promotes reuse rather than one-off closures:

// F#+PFA
const add = (x, y) => x + y;

add(1, 2); // no closure

ar |> add(?, 1); // no need for closure

const addOne = add(?, 1);

ar1 |> addOne;
ar2 |> addOne; // reused

// vs F#-style with only function-returning functions
const add = x => y => x + y;

add(1)(2); // produces short-lived closure

ar |> add(1); // produces short-lived closure

const addOne = add(1);
ar1 |> addOne;
ar2 |> addOne; // reused

PFA is good for all three cases. Function returning is only good for one case.

don't mind the overhead of returning a closure, then maybe x |> foo(a, b, c) seems like a win. Performance wise, it isn't.

We know this, but will library authors? I have done horribly inefficient things in the name of clean looking code when I was a novice.

// Hack-style
x = ar
    |> f(#)
    |> # + #;

// Plain-old JS
var _;
x = _ = ar,
    _ = f(_),
    _ = _ + _;

or if you want it to look all sigil-y:

x = _= ar,
    _= f(_),
    _= _ + _;

IMO the only thing Hack-style pipes do better than F# is await and yield, though you can still address those with parens:

// Hack-style
a |> await f(#) |> yield g(#);

// F#-style
yield (await a |> f(?)) |> g(?);

Though there was a proposal to address await and yield as a special operation:

a |> f(?) |> await |> g(?) |> yield;

Though there was a proposal to address await and yield as a special operation:

I just mentioned that above, apparently there are ASI issues:

And as far as Hack-style's benefit for x |> # + #, that can be achieved in F# using an arrow, and we could theoretically inline arrows statically within the spec as well:

x |> (_ => _ + _)

The only thing that would care that it's not actually a function would be a stack trace, but I'm ok with that.

In F# style, you could just fall back on an arrow:

x |> (_ => _ == null ? null : f(_) |> ...)

i.e., C# supports .. in collection initializers:

int[] x = [1, 2, ..y];

Though I had thought about using :: for a syntactic event mechanism. It was used for events in a different way in early versions of IE/JScript:

function window::onload(e) {
}

My thought was to use event to describe named events in a separate namespace (similar to #) and :: to access them, e.g.:

class Button {
  event click;
  event dblclick;

  raiseClick(e) {
    this::click(e); // can only invoke 'click' using :: when lexically inside class
  }
}

const b = new Button();
b::click += e => { };
b::dblclick += e => { };

I kind of feel like we’ve gone in circles over this over the years.
I already did a somewhat thorough review of what big open-source JS projects actually do for the current pipe proposal readme.
Almost nobody actually uses _ = …, _ = …. What people do use is deeply nested parenthesized expressions, mostly for function calls and await expressions, but also sometimes for object literals, array literals, and template literals. We can say things, “They should just break up all of those up into statements with different variables,” or, “They can already reassign to a dummy variable,” but the fact remains that almost everyone doesn’t do this. They deeply nest expressions in consolidated statements as if they were method chains, except with lots of recursive parentheses.
Many of the real-world examples I found are still in the readme.

I do agree with Justin that the most important feature of Hack pipes is that, like other pipe styles and like call-this, it encourages DCE-friendly API use. I agree that it’s a mere secondary convenience that Hack pipes do accommodate mixing different styles like function calls, member access, method calls, object/array/template literals, and the like in a unified postfix style.

Nevertheless, I do not agree that “people can already just use _ = …, _ = …; therefore Hack pipes are not beneficial”. The fact is that, even if developers already can use ,, and even if they can already break every await into a separate statement, they simply they do not. They continue to create poorly readable, deeply nested expressions everywhere. They want a fluent syntax that accommodates these somehow, whether it be Hack pipes or something else.

Almost nobody actually uses _ = ...

I don't expect they do. I do expect there are many instances of

const a = f1(x, ...)
const b = f2(a, ...)
const c = f3(b, ...)

in the wild, which is essentially the same thing. My point with _ = ..., is that it readily reproduces Hack-style behavior with no new syntax. It greatly sours the value of Hack-style for me, as I'd initially hoped for a simple syntax to give me more power over function application (tacit or otherwise), which is a far more novel capability.

They want a fluent syntax that accommodates these somehow, whether it be Hack pipes or something else

Agree with this. I like that Hack feels like regular code sequences, and can break them up to be much more readable. I think people would use this more than I would personally like, but the end result will still be readable code.