The practical benefit is that, unlike say Lodash's chaining, it is outwardly extensible, you don't need to write every function into a big object (and worry about naming clashes).
_.chain(inputSet)
.filter((x) => x >= 0)
.map((x) => x * 2)
.thru((e) => new Set(e))
.value()
Assumes chain returns a object with {filter, map, thru, value}, and if you want a new operation you need to assign it to that object, which means the library that returned the original object must expose that too, and everyone knows "Prototype Extension Is Bad" since you could come up with a method name that someone else came up with too, then you'd override things and introduce bugs.
With chaining (even ignoring the % Hack syntax for placeholder expressions) you can use functions from anywhere: local variables, other objects, anything you want, even if the library that provided the original data is not viable to modify, since it doesn't need to be modified.
Another way of approaching this extension problem is, well, with extension members, like Kotlin or C#, where you can declare free functions to operate on a "this" of a specific type, and then you can use it exactly as if it was a method of the type. Of course, JS is dynamically typed so that wouldn't be viable in this case.
Finally, I think that for JS specifically, a pipe function is enough. Sure you have a few more commas around but it's fine. I could see the appeal of having an operator in TypeScript, since it would mean that types would be preserved much better.
You can make a similar argument for JSX, private properties, etc. The point is that there will always be use cases that see massive improvements from a feature, but that doesn’t mean it’s worth adding it to the language and paying the price in specification and implementation complexity, surface area and learning curve. Especially if it doesn’t enable any new use cases.
If the 5% of people that benefit can get 90% there using userland libraries, the cost of that 10% improvement should not be bore by the other 95%.
I believe "harder to learn" is highly subjective in the same way that Japanese is hard to learn for a native English speaker but easy to learn for a Chinese.
Granted, Haskell and Scala are pretty "rich" and not beginner-focused.
OTOH, a language like Elm has a pipe operator and manages to keep things pretty simple.
Now does javascript need the added complexity? Tough call.
> Japanese is hard to learn for a native English speaker but easy to learn for a Chinese
This isn't to detract from your overall point but I study Japanese and many of my fellow students are Chinese, they certainly don't find it easy, even with the advantage of being able to infer most kanji. Korean to Japanese might fit the example better.
Well, if we assume that as they can read better they can prepare better, and that they’re relatively time rich as students; whereas in my group we all work, have families etc, it might be harder to make that advantage count?
Whatever the reason, I do envy their kanji skills!
there's "esoteric" as in fundamentally complicated, and """esoteric""" as in syntax that's unfamiliar but easily explained w/ a quick web search.
i believe "it's nicer to express some things this way" is a very important practical benefit. for me, "being expressive for experienced users" is ultimately more important to optimize for than """learnablility""", scare quotes intended. because beginners will be beginners for a while, and then they won't. (i dislike e.g. Go for this reason, but let's not get sidetracked)
(before you or someone else asks: i've tutored many beginner/first-time programmers, and yes, i still think a bit of syntactic sugar won't hurt them)