@jfftck

The biggest issue with this video is that it uses examples that don’t show the advantage of using a pipeline. It would have been better to use something that was a series of functions instead of a chain of methods, as this proposal is designed to replace nested functions. If that had been shown, most people would go for hack, since it would use a character to pipe the output into the next function and would allow functions with multiple parameters to specify which one to provide.

An example: subtract(%, 8) vs subtract(8, %)

As seen above, the function would be the same but the result would change due to the order of the values. So, this is designed to turn something that is a set of functions into something that looks similar to chained methods, which would change the following:

trim(lowercase(“ Hello “));

To this:

lowercase(“ Hello “)
|> trim(%)

The proposed syntax isn’t exactly designed for already existing chained methods, but rather to bind multiple functions into something that resembles using chained methods.

@DiogoScarmagnani

Wow! I didn't know about that comma chain syntax when two or more values are in parenthesis. Thank you.

@matthew_jackson

The F# version, to me, seems vastly superior. It doesn't rely on obscure or unique syntax other than the new operator itself.

@JamesDiGioia

Hey! Love this video. I worked on this proposal quite a bit over the years (as a community member; I'm not on TC39). Couple of quick notes:

1. As you mention, the F# version has been rejected multiple times, and the pipeline operator advanced to stage 2 as the Hack proposal.
2. There are a few reasons why F# has been rejected a few times: a. the runtime cost of creating new closures. b. the inability of the F# proposal to support await mid-pipeline without workarounds (part of the proposal was a "unary await" but this always felt like a bit of wart) c. the general impedance mismatch between unary-functions (and its cousin, currying) and the broader JS ecosystem.
3. The Hack version is actually at its most powerful not when translated method chaining but in unwinding nested expressions. People look at it as a cousin to method chaining because it looks syntactically similar (and admittedly, some of the initial motivation was "importable methods" a la RxJS) but that's not actually where it's at its most useful, and I would love to see more exploration of the Hack pipe that dives into this use case.

Thanks for covering this! I think the proposal has stalled out a bit (for reasons unrelated to the F#/Hack split) so I hope this can help breathe some life into it again.

@robwatson826

That comma chain syntax is very interesting.  It's been a while since I learnt something new about JavaScript, thanks Jack!

@rak3shpai

It's worth noting that while the examples show array iteration, that's not the important part of the proposal. The actual interesting thing that's happening is function composition. In the F# syntax, it can be point-free, and the previous call's return value is 'piped' to the next function's argument implicitly as the first positional / unary argument. In the Hack syntax, there is no need for it to be a unary function, as the % lets you use the argument in any positional location, but loses the point-free goodness. The F# syntax is more elegant but more restrictive - in real-world scenarios you will probably end up doing a lot of partial application to make the most of it. The Hack syntax, though not as elegant, might be the more practical thing to use.

@feldinho

It's funny having a functional concept being imported from a dialect of PHP (Hack).

I'm partial to the Hack version, since the F# ends up having more overhead because of the extra closures for naturally chained methods (two new closures per line instead of one). I'd be happy with any of those, though. 

Also, I think a better case for the pipeline would be for expressions like f(g(h(a))), comparing it to the flow function from Ramda/Lodash.

@CrapE_DM

Pipeline is great, especially for something that you CAN'T already method chain. It's meant to make nested function calls better

@AbhiShake-pl3cf

Woah the (0,1,2) thing is so damn helpful. I didnt even know that was possible. Its just so damn useful

@augiedb

The pipeline operator is awesome in Elixir because the language is made with it in mind.  These two JavaScript proposals need better examples, though.  Comparing the pipeline operator to method chaining limits what you can do with the pipeline. If it’s a series of custom functions you’re chaining together, it makes more sense.

@oserodal2702

JS 🤝 C++: Comma is an operator (TIL)

@MattMcT

Dude! DUDE!! This is going to be insanely useful for design system state logic systems. Love this proposal. Thank you for your work as always Jack!

@Jabberwockybird

Clear code is better than clever code

@eleah2665

Hi Jack, great to see you. Very informative. Thanks.

@astrosloth2

Am I the only one who does not get the hype for this?

@jondycz

Filter, map, reduce... All those also take a function as a parameter. So you could have done the same as in your F# example - console logging, then returning the expected value

@karamuto1565

The F# version looks more fitting for JS as JS is all about functions. 

I would love to see this as it kinda reminds me of the pipe operator from rxjs

@Nonsense116

Personally I like the F# version. It's a bit more clear to me that it's "just a function" whereas the "%" feels a little "magical" to me.

@af2b

|> amazing!

@vetrivendhan6122

Good to see this. This just differentiate method chaining and functional chaining. This force freshers to use pure functions. People who knows about functional programming really loves this. This will really improve code quality. There is no need to complicate your code with bind, call, apply, OOP concepts and fight with 'this' keywords.

Edit: yes it does not force to use pure functions but the code with pipe operator suggest freshers to use pure functions.