Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pipe Operator (|>) For JavaScript

github.com

Post reply on HN
Print view View original

11–20 of 437 posts

Re: Pipe Operator (|>) For JavaScript

#11

Post by icholy »

fnimick wrote: post #9
CyberDildonics wrote: post #4

I don't see how syntactic sugar makes any sense for javascript. Breaking compatibility is so severe because every browser needs to catch up, yet it doesn't actually enable anything that couldn't be done before.

It lets a transpiler like Babel or Typescript use the new syntax and output the equivalent code that works on older browser. Same reason async/await was useful far before there was native browser support - you could immediately use it in your codebase and compile to a legacy browser target.

I just don't want to use source maps anymore ...

Re: Pipe Operator (|>) For JavaScript

#12

Post by binarymax »

CyberDildonics wrote: post #4

I don't see how syntactic sugar makes any sense for javascript. Breaking compatibility is so severe because every browser needs to catch up, yet it doesn't actually enable anything that couldn't be done before.

Indeed. The argument of “nested calls are hard to read” is strange, because this looks terrible

Re: Pipe Operator (|>) For JavaScript

#13

Post by ollien »

dmix wrote: post #8
leishman wrote: post #2

I love the pipe operator in Elixir!

The current JS one isn't as nice as the Elixir one, at least it wasn't when I tried using it via Babel a couple yrs ago.

The JS one does seem to have some more power than the Elixir one. For instance, in Elixir, if it's a bit kludgy to pipe to a second or third argument. I find this often when I want to insert into a map. You can always define more functions, but otherwise it's annoying, because you end up with something like

  computation() |> &(Map.put(my_map, key, &1)).()
That said, with this less-power, you do kind of end up forced to design your functions in a way to where piping makes sense, and IMO it leads to cleaner and more consistent APIs.

Re: Pipe Operator (|>) For JavaScript

#14

Post by [deleted] »

hajile wrote: post #3

They should have stuck with the F# proposal. The hack proposal just takes one more giant step toward turning JS into Perl. Hack proposal value |> foo(%) for unary function calls, value |> foo(1, %) for n-ary function calls, value |> %.foo() for method calls, value |> % + 1 for arithmetic, value |> [%, 0] for array literals, value |> {foo: %} for object literals, value |> `${%}` for template literals, value |> new Foo…

[deleted]

Re: Pipe Operator (|>) For JavaScript

#15

Post by hajile »

CyberDildonics wrote: post #10
fnimick wrote: post #9

Earlier quoted context omitted.

It lets a transpiler like Babel or Typescript use the new syntax and output the equivalent code that works on older browser. Same reason async/await was useful far before there was native browser support - you could immediately use it in your codebase and compile to a legacy browser target.

If you're compiling to javascript anyway, why would you need a pipe operator in javascript instead of just nesting the function calls?

Because x |> f |> g |> h is much easier to read than h(g(f(x))) for most people.

Re: Pipe Operator (|>) For JavaScript

#16

Post by CyberDildonics »

hajile wrote: post #15
CyberDildonics wrote: post #10

Earlier quoted context omitted.

If you're compiling to javascript anyway, why would you need a pipe operator in javascript instead of just nesting the function calls?

Because x |> f |> g |> h is much easier to read than h(g(f(x))) for most people.

If you're compiling from another language you would be using whatever syntactic sugar you want, why break compatibility just to have the compiled javascript look a little better?

Re: Pipe Operator (|>) For JavaScript

#17

Post by pavlov »

CyberDildonics wrote: post #4

I don't see how syntactic sugar makes any sense for javascript. Breaking compatibility is so severe because every browser needs to catch up, yet it doesn't actually enable anything that couldn't be done before.

Every browser these days just means Chromium and WebKit, so all it takes is that Google and Apple need to agree.

Firefox usage is down to a rounding error, and they happily implement whatever the commercial duo decides the web should have.

Re: Pipe Operator (|>) For JavaScript

#19

Post by qbasic_forever »

CyberDildonics wrote: post #4

I don't see how syntactic sugar makes any sense for javascript. Breaking compatibility is so severe because every browser needs to catch up, yet it doesn't actually enable anything that couldn't be done before.

Browsers have established they can roll out changes behind feature flags, and the community adapts and adopts them. This is a solved problem. ES6 transition, await/async, string templates, etc. were major JS changes that required browsers and runtimes to change. They did. It was fine. They can do it again!
Post reply on HN