The advantage is that you don't have to name things. "v" is a bad name in a larger context, and it quikly becomes unwieldy if you use a full name.

    let transformedData = transformFoo(data);
    transformedData = transformBar(transformedData);
    transformedData = transformBaz(transformedData);

 vs.

    const transformedData = data
      |> transformFoo
      |> transformBar
      |> transformBaz

If you want have const's the first becomes even more unwieldy, and in general I'd recommend using const by default.

Just like lambda syntax makes it much easier and readable to write small functions, the pipe operator make it much easier and readable to write chains.

I find |> annoying to type. How about making it so unary functions can be invoked like this?

  arg function_name

Then instead of

  arg |> func1 |> func2 |> func3

you could simply write

  arg func1 func2 func3

It might get a bit ugly when used with arrow functions instead of named functions, and there might need to be a special case when arg is a function, but if those problems could be handled not too unreasonably this seems a fine approach for a programming language.

> Just like lambda syntax makes it much easier and readable to write small functions, the pipe operator make it much easier and readable to write chains.

succinct =/= more readable.

Readability here is really in the eye of the beholder...

It's certainly quicker to type, but that's not a good argument enough to make such a drastic change in javascript.

> It's certainly quicker to type, but that's not a good argument enough to make such a drastic change in javascript.

I am so glad this argument has not been winning out in the JavaScript language design community. There are so many wonderful constructs that have been added in the last 20 years that are just sorter ways to write things that could mostly already be done in the language. Many of these features focused on allowing developers to write what they intended to do without having to explicitly construction the intermediate steps to express the mechanics of how that should be carried out using basic language features.

After all why do we need arrow functions when we could just sprinkle our code with `var self = this;` declarations for anonymous functions to bind to, the way it was done in the late 90's and early 00's.

I'd much rather JavaScript adopt succinct ways to write common code patterns and let the developers and the community decide if those constructs are the correct ones to use on a case by case basis.

> I am so glad this argument has not been winning out in the JavaScript language design community. There are so many wonderful constructs that have been added in the last 20 years that are just sorter ways to write things that could mostly already be done in the language.

Beware of survival bias, though. There have been many proposals that aren't part of JS today.

- One thing not discussed in the article is type safety. But TC39 increasingly considers the impact of proposals on typed extensions to JS like TypeScript/Flow. In your example, v must be a union type of the return types of each of the called functions.

- The pipeline operator can be used to assign to a const, to prevent further assignments. While const isn’t necessarily immutable, it is often idiomatically used to signal that the assigned value is intended to be final. The same can’t be achieved with your example without wrapping it in an IIFE, which is (IMO) much harder to follow than the pipeline operator.

- More subjectively, it (in the F# variant) encourages better interfaces. For most use cases where piping would be appropriate, it’s generally a good idea to make the data you’re processing the last parameter. This also, as the article notes, works well with partial application. Which in turn also encourages good practices like composition.

I think your first point is the only compelling reason (for me) yet I also hold the stance that TC39 shouldn't cater to corporate projects such as Typescript as they are not maintained by the same committee.

Those are my opinions, however.

I do agree that they shouldn't cater to TypeScript or Flow or anything specifically, but I appreciate that they think about the impact of new changes on typing JavaScript. I find in general that code that can easily be statically typed is easier to understand and maintain.

Exactly this! And the inverse—where JavaScript devs complain that TypeScript types are overly complex and verbose—is just a symptom of the same principle. Those types are complicated because your interface is complicated! If you had a clear data flow/model the types will usually end up being much simpler too.

This is somewhat less true in some frontend projects, where the underlying libraries/frameworks come with infectious built-in interface complexity (side-eyes React/JSX even though I quite like JSX otherwise).

> And the inverse—where JavaScript devs complain that TypeScript types are overly complex and verbose—is just a symptom of the same principle. Those types are complicated because your interface is complicated!

Part of it may also be due to the limitations of TypeScript. Structural typing is not always the best choice. ADT support is also not the best.

I definitely have wants for the TS type system, particularly in the area of nominal typing. But it’s usually not this IME. It’s usually that untyped JS often is written in an overly permissive style where anything goes, or where state and data flow is a big ball of mud, or both.

That's false equivalence. Typescript is trying to bolt on strict, formal types to a prototypical language. Because the language doesn't map cleanly into formal types doesn't mean it's poorly designed. You'd need to have a lot of evidence that that were the case, as it's a bold claim about not just JavaScript, but programming language design in general - one that isn't entirely factual, IMO.

Look at shell scripting. Imagine trying to apply a type system to shell scripts. It wouldn't map cleanly at all because (almost) everything is a string, and the operations define how those strings are interpreted - not the data itself.

However for what it is, shell scripting is quite useful. Most would argue it has a simple interface, simple syntax, simple concepts.

Perhaps a contrived example - my point mostly being that you can't draw conclusions like that.

> Because the language doesn't map cleanly into formal types doesn't mean it's poorly designed.

Oh, I wasn’t saying the language is poorly designed. I was saying the particular JavaScript code where people complain about the TypeScript types is usually poorly designed. It’s not the types’ fault the interface is so convoluted the types describing it are also convoluted.

Like people write variadic functions that take arguments, or an options map, or a boolean, or a magic string or enum… and then say “there’s 100 lines of types describing this functiona! That’s such a pain!” And like, yeah, it is a pain understanding what your function does.

> Look at shell scripting. Imagine trying to apply a type system to shell scripts. It wouldn't map cleanly at all because (almost) everything is a string, and the operations define how those strings are interpreted - not the data itself.

Amusingly, you’d end up with a type system a lot like TS. Particularly template literal and mapped types.

> However for what it is, shell scripting is quite useful. Most would argue it has a simple interface, simple syntax, simple concepts.

I think this is the only point of disagreement for me here. I find shell scripting absolutely painful, and try to do as little of it as possible.

> Look at shell scripting. Imagine trying to apply a type system to shell scripts. It wouldn't map cleanly at all because (almost) everything is a string, and the operations define how those strings are interpreted - not the data itself.

Everything is a string because every program deserializes and then serializes data from and into a string. But you still have expectation encoded into the tools. If not, they wouldn't be able to work together. Static typing is about making these expectations explicit.

They aren’t catering specifically to TypeScript (or Flow), but rather to increased interest in type safety across the community generally.

It’s worth noting though that the TypeScript team does participate in the standards process. And Microsoft has two members on the committee.

In your example you're mutating v, which is something people try to avoid these days, as immutable data is easier to work with. There's also a good chance you can't find a good name for v that fits what it is at every step. A good part of the pipeline operator is that you don't have to name every step. Sometimes there's just no good name.

> as immutable data is easier to work with

Source? This hasn't been my experience. Going on 10 years of heavy Node.js ecosystem involvement, immutable data enthusiasts are exceedingly rare.

Plus, this is const vs let, which is a reach to call "immutable data". We're not talking about object properties.

> Source? This hasn't been my experience. Going on 10 years of heavy Node.js ecosystem involvement, immutable data enthusiasts are exceedingly rare.

Immutable.js is relatively popular and immutable records and tuples are a stage 2 TC39 proposal. From what I've seen, immutability is mostly popular on the frontend, probably because functional programming had a huge impact there. It's also popular in other languages (FP or FP inspired generally, so OCaml, Haskell, Scala, Elm, Elixir, Rust) that are relatively close to the web ecosystem.

> Plus, this is const vs let, which is a reach to call "immutable data". We're not talking about object properties.

I'm not sure what you mean here.

A variable being mutable (let vs const) is not the same as the data referenced by that variable being mutable. There are languages that favor immutability (Elixir, for instance) that permit rebinding of local variables.

> Source? This hasn't been my experience. Going on 10 years of heavy Node.js ecosystem involvement, immutable data enthusiasts are exceedingly rare.

Not an authoritative source, but since you cite your own experience, mine has been the opposite. Especially so when TypeScript is also in the mix.

> Plus, this is const vs let, which is a reach to call "immutable data". We're not talking about object properties.

As I mentioned in a sibling comment, const is often used to signal the intent to treat an assignment as immutable. This isn’t universal, but I understand it to be idiomatic usage.

State in React should be immutable. It’s not rare at all!

React != JavaScript.

Yeah, of course. But vast majority of React is written in JavaScript and large numbers of JavaScript devs are writing React. It shows FP and immutability have significant base of practitioners in JS world - although many might not realise it.

I would argue most JavaScript developers do not use React. Perhaps in your own bubble, but there are way more people writing other things in JavaScript.

    return first() | second(_, 10) | third(x, y, _)

I somewhat agree.

Further, it has to be |> to disambiguate from bitwise OR. So yet another symbol to confuse readers.

And the placeholder can't be _ as that's a valid identifier. The first issue on the tracker is the bike shedding thread about what the placeholder symbol should be, and it's neither _ nor ^, but instead probably something like ^label.

I think it's kind of ridiculous to say you can't use _ because it is a valid identifier. You could just have the pipe _ shadow the identifier _ if said id is present. I suspect the bigger reason is because of underscore/lodash being in wide use.

Suppose you had "const _ = 42; /* more code / return x | f | g(11, _);". This would be semantically equivalent to "const _ = 42; / more code */ return ((_) => g(11, _))(f(x))". Since it is a new function, shadowing is not forbidden.

I'm not the one saying it, check #92 I believe it is. The bike shedding thread. They don't want to shadow.

Agree what? You can't overload bitwise with another semantic