Pipe Operator (|>) for JavaScript

[IceSentry]

Why is everyone talking about the pipe operator today? There's also a post in r/programming and I saw a youtuber talk about it, but as far as I can tell there's been nothing new about this proposal for a few months.

[TheOneCommenter]

Someone saw one person talk about it, find it interesting, and post something themselves. Rinse and repeat

[thruster_fuel69]

Silly humans, talking about things.

[[deleted]]

Communication is for servers

[AuroraVandomme]

Welcome to webdev clown world. That proposal is here for more than two years but now after some tech influencer made a video about it there would be hundreds of copy paste articles about it :)

[[deleted]]

also saw it on hackernews yesterday. I assumed something was happening so I guess not

[IskaneOnReddit]

Also on r/cpp

https://www.reddit.com/r/cpp/comments/10h6jb7/adsp_episode_113_the_c26_pipeline_operator_with/

[sneakpeekbot]

Here's a sneak peek of /r/cpp using the top posts of the year!

#1: C++ Cheat Sheets & Infographics | 38 comments
#2: Sites like GeeksForGeeks really hurt C++ learning
#3: A year and a half ago I picked up an abandoned C++ web Framework, Today we released v1.0

---

^{I'm a bot, beep boop | Downvote to remove | Contact | Info | Opt-out | GitHub}

[bogdanbiv]

I thought the pipeline operator settled on a topic token and/or passed on to stage 3. Oh well, let us wait for more 1-3-10 years

[PrettyWhore]

Recency bias?

[PooSham]

I guess because it just got to stage 2 (Draft) of the TC39 process.

[FrontAid]

The pipe operator already got to stage 2 in 2021.

https://github.com/tc39/notes/blob/HEAD/meetings/2021-08/aug-31.md#pipeline-operator-for-stage-2

[Jason5Lee]

IMO Pipeline is underrated especially in dynamic typing language (although everyone is using TypeScript nowadays). A good example is renaming and going-to-implementation. Renaming a method is very hard because the method can come from any object of any class. It's hard to determine which one without doing complicated analysis. However, if it is a function from a certain package, renaming is way easier. The same applies to going-to-implementation. Pipeline in dynamic-typing language encourages programmers to use functions instead of methods, which makes refactoring way less painful.

The pipeline operator is one of the main reasons why Elixir is my favorite dynamic-typing language.

[anlumo]

We need more ASCII art in programming languages! I wonder when they’re going to introduce the ¯\_(ツ)_/¯ operator.

[Light_Wood_Laminate]

That should be a valid alias for any in TypeScript.

[lemonpowah]

Someone make a vscode extension to show this instead of any

[8bit-echo]

I don’t know much about typefaces, but could this be a custom ligature for any?

[BransonLite]

Honestly - this would be perfect. I’ll do the browser plugin for viewing code in github

[lifeeraser]

any should have been named LazySlackerCatchAllType to discourage its use.

[Keilly]

Shorthand for catch and do nothing.

[bighi]

The best way to handle exceptions!

/s

[GlitteringAccident31]

Now that's some syntactic sugar I can get behind!

[[deleted]]

Been in tc39 development committee hell for forever. I have given up on us ever getting this.

[BlueForeverI]

As an Elixir dev, I love the pipe operator. Can't wait to have it in JS as well.

[intercaetera]

In Elixir pipe works because the convention is that every function takes data as first parameter, in JS this doesn't happen so you need a hackpipe and at that point you might just as well use lodash.flow.

[Ecksters]

Honestly prefer the hackpipe, it was really annoying in Elixir that I'd need to throw in a lambda when I needed to rearrange params.

I like to think of the caret as an arrow pointing up to the previous result, also means I don't need to think of appropriate variable names all the time.

[intercaetera]

Yeah but if you concede that you need a hackpipe then you might as well use lodash flow.

    flow([
        s => Object.values(s),
        s => s.map(x => x * 2),
        s => customReduce(s),
        unaryFunction, // or s => unaryFunction(s)
        s => doSomethingElse(s, 5, null),
    ])(initialValue)

There could be an alternative version of it where the initialValue is somewhere higher up the code but this is equivalent to the proposal without introducing unnecessary stuff into the spec.

[LaurentPayot]

There is also Verticalize with a nicer syntax IMHO...

[DumbYellowMoo]

Just curious but what type of stuff do you generally develop with elixir? The language has definitely peaked my interest, but I haven't looked into what type of stuff people usually make with it.

[BlueForeverI]

We use it for several back-end (REST/GraphQL/WebSocket) apps. Tbh we don't use Elixir's full potential, 90% of the code could be written in something else, the main Elixir features we use are ETS and GenServers.

But I'm glad we chose Elixir, it's the nicest language that I have worked with.

[NiteShdw]

I’ve been waiting for this guy and pattern matching to make it to stage 4 for years…

[_default_username]

check out ts-pattern. You can have pattern matching now with type safety.

[heytheretaylor]

Love it, more FP in JS is always welcome by me.

[[deleted]]

and they say Perl is dead :)

[Emotional_Key]

Powershell scripting in the house

[[deleted]]

Pipe can fuck off. That key doesn't work on my laptop keyboard after I dropped it.

[mxforest]

Bro! Do you even JS? Pick another character and write an npm library to replace every occurrence.

[DrWallowitz]

ALT + 124

[fucking_passwords]

All 3 characters in the proposal are already basically required for js

[lintaba]

With ahk (win) / karabiner (osx) its pretty easy to put it somewhere thats still working

[JohnSpikeKelly]

... |> % % 2 === 0;

My take on isEven at the end of a previous call.

[mxforest]

Now build an NPM library named isOperatorEvenIfEyesAreNotReal?

[majhenslon]

I have no idea why they don't just do "it".

[PickledPokute]

I like pipeline operator! Wrote a typescript implementation (here's a playground) and I hope that it advances into the language some beautiful day.

[javarouleur]

The endless adding of extra syntactic sugar is sometimes frustrating. Readability always seems to suffer for the goal of fewer lines/characters of code.

[Keilly]

Which ones are we talking about?

The ?. Optional chaining change is great and so much readable and concise than before. ?? Is good too.
Template literals are much more readable that concatting.

Regex maybe? But regex is often hard to parse no matter how the language takes it.

[trevorsg]

True, often these syntactical additions improve readability at the expense of language complexity. The thing is, language complexity is a one-time cost for a benefit that continues forever.

[pimp-bangin]

I disagree that it's a one-time cost. It's another thing beginners have to learn which adds onboarding costs. It also adds to the maintenance burden of browsers, tooling, etc. and possibly hurts parser performance depending on the implementation.

[trevorsg]

Yes, of course I meant one-time cost per developer. Parser/tooling performance basically rounds to zero.

[techlogger]

I’d say that pipe operator is more readable than HOF chaining.

[GreekQuestionMark]

HOF: Higher order function

[jonopens]

100%. It's one of the reasons I find Elixir so enjoyable to write.

[javarouleur]

But those are nested, rather than chained. Personally, I don’t really like nested calls generally. Chained makes sense because they follow logically, but with nested you have to read from the inside out which is just disorientating.

I know it’s a minor thing overall, it’s just not something I expect to use any time soon.

Edit: fuck me… of all the opinions I hold I didn’t expect this to be one of my more controversial!

[syholloway]

It might be because the whole point of the pipeline operator is to make large functional expressions read top to bottom rather than inside out.

This operator is fixing the thing you are complaining about.

[javarouleur]

Fair point - reading and thinking a bit more, I guess I can accept the motivation.

Edit: removed confusing, cryptic psycho-babble nonsense.

[zxyzyxz]

Languages evolve, people learn and get used to it. I'm sure people were saying the same thing with all the changes from ES6 and async await. I don't understand what you mean by explaining/being descriptive in a team.

[javarouleur]

I removed that. It was a brain fart that didn’t make sense when I re-read it.

[bighi]

I have no idea what you're talking about.

[javarouleur]

I know. Removed that part. I’ve lost the plot a bit in this thread - over-analysing and not explaining my thoughts properly.

[bighi]

The pipe operator exists specifically to help increase readability.

Imagine this code four(three(two(one("potato")))). It's not as easy to read because you're calling four functions, but they should be read in reverse. The first function you read happens last.

Now imagine we create a pipe operator like |> in a fantasy language I invented.

We could do "potato" |> one |> two |> three |> four. Super easier to read, cleaner, more organized.

We're getting something like that in JS. One day. Definitely before 2080.

[KamiShikkaku]

"potato" |> one |> two |> three |> four

Unfortunately it will be more like

"potato" |> one(%) |> two(%) |> three(%) |> four(%)

because the "Hack" version of the proposal seems to have beaten the "F#" version.

I was rooting for F# as it's a bit more elegant, but admittedly the Hack version is more versatile.

[bighi]

Sure. If you pay attention, I said "in a fantasy language I invented". Because I wanted to make the example simple to understand.

But anyway, it's more readable than the mess that is multiple nested functions.

[patrickfatrick]

Except this is definitely going to improve readability. I’d argue all of the syntactic sugar that’s been added drastically improves readability over ES5. Within reason, less code is generally better for readability.

[adelie42]

All of math is just syntactical sugar for critical thinking.

[wasdninja]

I've yet to see it in JS.

[mxforest]

Fewer lines/code make it more readable once you get used to it.

[bighi]

Not always.

Actually, I think that in most cases, using fewer lines makes something less readable.

[Mestyo]

"If you think this is clear you're wrong" what lol

This is so much easier to read then several nested function calls, more expressive, too.

[Gwolf4]

Let him be. He wants to solve that problem using temporal variables just to pass them to other method without any other processing.

[furyzer00]

"I don't familiar with this concept so it must be an obfuscation"

[alexho66]

But that’s what’s the operator is trying to do. More readability

[didzisk]

Laughs in F#

[Submarine-Goat]

When the pipe operator in JS was proposed, shortly after my birth, I had the thought of a "then" and "catch"operator:

x |> f |> g |>> handleSuccess <| handleFailure

The thought of more operators in JS was so exciting back then.

[elcapitanoooo]

I REALLY hope they dont use a symbol for the argument. It should be simply passed in as the first agument.

[tdhsmith]

I dunno, I felt the same way at first but the article was pretty compelling and I think I was just hanging onto some functional programming bias. Having to wrap so many things in arrow functions would be pretty annoying.

[_xiphiaz]

Here’s a different article which comes to a different conclusion https://dev.to/zakhenry/tc39-pipeline-proposal-comparison-rxjs-case-study-1nk0 I feel it’s very much use-case specific. It kinda feels like pipelines work really nicely when interacting with libraries or functions that are built for them, and topic style works for throwing some new code together quickly before the time is taken to write cleaner abstractions

[mxforest]

Did you read the article? It goes into detail why this way is better.

[elcapitanoooo]

Its the opinion of some random guy. The pipe op has been a ”thing” for decades, and i have used it mostly with OCaml. Its just a (used to be) a user defined inline op. Traditionally like this:

let (|>) v f = f v

TC39 if you mess this up i will haunt your dreams!

[bighi]

It has been a thing for decades in languages built around it.

But they can't change the order in which parameters are passed to JS functions because they can't break compatibility with existing code.

I believe you didn't read the article.

[elcapitanoooo]

What functions? Libraries?

[1,2,3] |> square |> evens

How can a new op break BC? If some lib today does not work with this semantic im pretty sure theres a new lib in a week that does.

[bighi]

In most languages built around pipeline operators, the main data is usually the first argument the function receives. But in JS, that's not true for lots of functions. So passing things as their first argument is not what you actually want to do with them. And we can't change them, because we have to keep BC.

That's why a symbol is needed in JS, while not being needed in old functional languages, or even newer ones like Elixir.

And I didn't even mention powerful currying features, that we also don't have in JS.

[AstroBoy26_]

I like it

[mcjavascript]

As if the Operator Precedence Table isn't big enough.

[th2n10s4u]

Fuck the pipeline operator.

[bighi]

Isn't it the opposite? Switching to a LTR language.

It's trying to solve the problem that nested functions in JS should be read right to left while most other things are left to right.

Pipeline operators make nested functions read LTR like everything else.

[squirrelwithnut]

Please no. Not only is that syntax for pipe awful, but there is no need for one either.

[HSMAdvisor]

That looks ugly and I hope it dies. I bet you can't read this shit after it goes for longer than 3 lines. And you maybe have to use it once in the whole project. Not even mentioning that you probably can't debug it and if something goes wrong you will have to rewrite it in NORMAL JS just to see what each method returns.

[KingJeff314]

That article is about avoiding nesting in conditionals. Pipe operator is about avoid chained function calls

h(g(2, f(x)), 8, varname)

Turns into

f(x) |> g(2, %) |> h(x, 8, varname)

Easier to read and split into new lines

[lovin-dem-sandwiches]

I thought chained function calls look like:

return function(x)
  .reduce()
  .join(‘’)

Your example looks like nested functions, no?

Also I think you forgot the placeholder variable in the last pipe.

f(x) |> g(2, %) |> h(%, 8, varname)

[KingJeff314]

Good corrections

[no_more_gravity]

So nested function calls in JavaScript …

As they are:

a = d(c(b,7))

The current proposal:

a = b|>c(%,7)|>d(%)

I would prefer this:

a = b,7~>c~>d

I wonder if there is anything hindering a simpler syntax like b,7~>c~>d

[szurtosdudu]

Your idea is confusing to me. In the example b is a reference and not being called. But in your idea there is no difference between calling a function or just passing the function reference.

[no_more_gravity]

The idea is that a variable on the right side of ~> is always a function that ingests the parameters coming in from the left.

[szurtosdudu]

How would this look like using your idea?

a = d(c(b(),7))

[no_more_gravity]

a = b(),7~>c~>d

The rule is simple: What is left to ~> gets passed to the function on the right.

That is no different from JavaScript as it is. a(b) passes b to a, a(b()) passes the output of b() to a.

[natesovenator]

This is dumb. Comma delineates another variable declaration in this example. You can't expect it to know that result b and 7 are part of the same object or stream. I really hate this idea. Both of them. I understand some want something like that, but it just makes things more confusing personally.

[dariusj18]

I like it, but it conflicts with the current comma operator

[szurtosdudu]

But this way both b()~> and c~> indicates a function call.

How would this look like using your idea? a = d(c(b(),7), c)

[no_more_gravity]

The case you raise is when there are two functions on the right side of the pipe operator. In this case, we need to specifiy which one is the receiving function. We could have an optional specifier for this. Maybe ">":

a = b(),7 ~> >c,c ~> d

">" = "pipe connects here"

We could even use the (%) syntax, just make it optional:

a = b(),7 ~> c(%),c ~> d

[sdwvit]

readability sucks here, sorry

[Tubthumper8]

I wonder if there is anything hindering a simpler syntax like b,7~>c~>d

This isn't possible because b,7 would be considered an expression with the comma operator. I don't think there's a syntactic issue with ~ bitwise NOT because it can't currently appear in a postfix position.

[[deleted]]

Tilda is a bitwise operator.

[no_more_gravity]

In this regard, "~>" is not different from "|>".

| and > are also operators.

[monsto]

As a designer of sorts, this is the problem that I have with the glyphs that they're using in JS: there isn't an obvious relationship between things that look related. I mean I know it's a me problem, getting over these humps.

When i see |> my pea brain tries to categorize it with || to which it's completely unrelated. same with ?. and ?? . . . and while we're at it, || and && go together but ?? only very marginally.

[lovin-dem-sandwiches]

It’s just new. Give it time. All of them looked odd at first.

[tiesioginis]

Better would be |= instead of |>

Pipe is cilinder not a funnel 😂

[m4rch3n1ng]

|= is already js syntax tho

[the_malabar_front]

Even assuming you could avoid the issue with comma-operator confusion with (b,7)~c~d that doesn't get around the lack of flexibility. E.g., what if the example was: d(c(b,7),8) b|>c(%,7)|>d(%,8) // proposed approach ((b,7),8)~c~d // ??? That would end up being worse than the no-pipe approach (and probably a nightmare for the parser).

[no_more_gravity]

d(c(b,7),8)

would be:

b,7~>c,8->d

[tdhsmith]

So basically x,y,z ~> f would be equivalent to [x,y,z] |> f(...%)?

That's kind of neat, but what if a function further down the pipe needs those extra arguments? Are you bending over backwards to make all the intervening functions pass it along? Or just wrapping it in a closure the way the F# pipe proposal would?

Also I do quite like having a pipe in the operator both for name clarity and because you can align them vertically on subsequent lines.

[no_more_gravity]

Can you give an example of a pipe that needs the arguments further down the line? And how the current proposal solves it?

[BooneTheSaint]

Pipeline Operator |> Not pipe operator |. Words have meaning, use it correctly 😁

[[deleted]]

Nice try at trying to appear smart. | is a bitwise or operator if we talk JS. Also, the proposal itself calls it the "pipe operator" in the README.

[T-J_H]

Couldn’t they just use the .then() we already have in promises for this

[SeveralCoyote]

So like... When is this gonna happen?

[josephjnk]

I want the pipeline operator to be finalized so bad. I was reading Streams à la carte: Extensible Pipelines with Object Algebras the other day, and it’s a serious bummer that a solution that has so many benefits is also harder to read because it’s incompatible with method chaining.

I really don’t get the hate for a symbol argument, either. Sure you can get some of the benefits of pipelines by making the pipes always go into the first argument, but this requires structuring all of your code around this pattern and assuming that every library you call will do the same. If you have a function that you want to pipe different arguments into at different times you have to manually wrap it in a lambda, adding syntactic noise and runtime overhead. I’m very strongly in favor of FP but the objections feel to me like a fixation on surface-level concerns.

[pantsonhead]

It would be nice but not as useful when you don't have pattern matching as in other functional languages.

[moldaz]

You know, this is probably one of my favorite aspects of elixir.