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

111–120 of 437 posts

Re: Pipe Operator (|>) For JavaScript

#111

Post by ubertaco »

eddsh1994 wrote: post #88
evnp wrote: post #68

const isRandNumOdd = Math.round(Math.random() * 100) |> % % 2 |> Boolean; Excruciatingly contrived, but does this sort of arithmetic work in the Hack syntax? I'm genuinely curious, couldn't find any mention of modulo (or remainder) in the proposal.

% % 2 Gross

...so only the first usage of `%` counts as a replacement?

What if I need the value to be replaced multiple times, like this:

   |> `${%.id}: ${%.friendlyName} ${%.url}`
I'm surprised they aren't going with an idiom like `$1`, `$2`, etc or something like in other languages that have "magic" lambda parameters.

Re: Pipe Operator (|>) For JavaScript

#112

Post by DarkNova6 »

arp242 wrote: post #27

Is this: Object.keys(envars) .map(envar => `${envar}=${envars[envar]}`) .join(' ') |> `$ ${%}` |> chalk.dim(%, 'node', args.join(' ')) |> console.log(%); Really better than: console.log(chalk.dim( `$ ${Object.keys(envars) .map(envar => `${envar}=${envars[envar]}`) .join(' ') }`, 'node', args.join(' ') )); That's the real-world example they have (I reformatted the second one slightly, because it looks better to me). N…

Wait, design by committee is not a good thing? Gasp

I can only hope this leads to Javascript becoming even more unbearable. Perhaps only this can weaken Google's resistance to WASM.

Re: Pipe Operator (|>) For JavaScript

#113

Post by capableweb »

Someone1234 wrote: post #96

Can someone remind me again why there's never been movement to add a second modern language to web-browsers? JavaScript was created in a weekend and then stuff tacked on for the last 28 years. We know so much more about how to create programming languages today than we did then, and the whole "Year of the Linux Desktop" has become a WebAssembly meme now every year since its introduction six years ago, with it getting…

WebAssembly is just what you want, a second "modern" language that works in browsers. It hasn't reached 100% of its potential just yet, as there are some things missing for that (like DOM access) but once the language is feature complete, I'm sure most languages will have some sort of "Lang to WASM" tooling that'll allow you to write React apps in Ruby or whatever, if you so wish.

Stuff like that takes time though, so if you're antsy, you have two options: get involved, or wait patiently.

Re: Pipe Operator (|>) For JavaScript

#114

Post by jsf01 »

matlin wrote: post #34

Can't wait for this. Pipes are awesome in Elixir and bringing them to JS/TS will be great. To me this is both concise and readable: const weather = `https://api.weather.gov/gridpoints/TOP/31,80/forecast` |> await fetch(%) |> await %.json() |> %.properties.periods[0]

While pipes are great in Elixir I think it’s important to look at the total cost to adding any new syntax in the context of the language that is considering them.

In the JS ecosystem, idiomatic nested function calls are read from the inside out. And in most cases that is highly readable because a single layer of nesting is all you need.

This proposal flips that on its head, so you have to retrain yourself to read code in a new way based on the presence of a |>. That adds significant cognitive overhead, especially in code that isn’t well written or that is already complex.

Your example looks nice, but also just as nice is the .then() syntax you could have used.

Now we’ll see code bases with both styles. You’ll have some team members who love pipes so much they’ll never call a function the old way doing x |> console.log and the rest of the team doing console.log(x).

Sometimes, limitations are a good thing.

Re: Pipe Operator (|>) For JavaScript

#116

Post by scotty79 »

arp242 wrote: post #27

Is this: Object.keys(envars) .map(envar => `${envar}=${envars[envar]}`) .join(' ') |> `$ ${%}` |> chalk.dim(%, 'node', args.join(' ')) |> console.log(%); Really better than: console.log(chalk.dim( `$ ${Object.keys(envars) .map(envar => `${envar}=${envars[envar]}`) .join(' ') }`, 'node', args.join(' ') )); That's the real-world example they have (I reformatted the second one slightly, because it looks better to me). N…

> Neither seems very good to me, and the |> version doesn't really seem "less bad".

For me the piped version seems way better, way cleaner, with cleanly separated processing steps.

I don't like nested steps because for nesting multiple arguments functions your expression tends to grow in both directions and parts belonging to the same step tend to end up really far from one another and clearly distingushes them from data that's pushed through the pipeline.

% is short so it keeps parts of the same processing step together.

This syntax also enables you to express which part is the data to be processed, what are the processing steps and what are additional parameters of the processing steps.

Re: Pipe Operator (|>) For JavaScript

#117

Post by ollien »

tytho wrote: post #75
ollien wrote: post #13

Earlier quoted context omitted.

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 t…

There is another way that isn't _as_ kludgy, but still not as nice as the JavaScript proposal: computation() |> then(&Map.put(my_map, key, &1)) It's the big reason the `then/2` function was created from my understanding.

Oh wow, TIL about `Kernel.then/2`. That definitely works around the syntax problem.

An aside, the implementation is kind of amusing. It almost seems unnecessary for this to be a macro but maybe the compiler can optimize this a bit more? I would expect TCO to simplify of my "simple" implementation of

  def then(value, fun) do
    fun.(value)
  end
https://github.com/elixir-lang/elixir/blob/a64d42f5d3cb6c327...

Re: Pipe Operator (|>) For JavaScript

#118

Post by DarkNova6 »

BigJono wrote: post #52
arp242 wrote: post #27

Is this: Object.keys(envars) .map(envar => `${envar}=${envars[envar]}`) .join(' ') |> `$ ${%}` |> chalk.dim(%, 'node', args.join(' ')) |> console.log(%); Really better than: console.log(chalk.dim( `$ ${Object.keys(envars) .map(envar => `${envar}=${envars[envar]}`) .join(' ') }`, 'node', args.join(' ') )); That's the real-world example they have (I reformatted the second one slightly, because it looks better to me). N…

TC39 proposals often have rubbish real world examples that should never see the light of day in a JS codebase. It makes me really question the judgement of the people that are working on this language, and it explains how some of the shittier proposals manage to slip in and why the good ones are misused all over the place in every real world codebase when this is the kind of guidance devs have on where to use fancy n…

> It makes me really question the judgement of the people that are working on this language

Only now?

Re: Pipe Operator (|>) For JavaScript

#119

Post by lordgroff »

Someone1234 wrote: post #96

Can someone remind me again why there's never been movement to add a second modern language to web-browsers? JavaScript was created in a weekend and then stuff tacked on for the last 28 years. We know so much more about how to create programming languages today than we did then, and the whole "Year of the Linux Desktop" has become a WebAssembly meme now every year since its introduction six years ago, with it getting…

Because there's not that much wrong with modern JS, with the "created in a weekend" mantra being wholly irrelevant.. Back when JS was trash there was was Coffeescript and other lesser used alternatives, and Google tried to push Dart but nobody cared. Today is pretty much only JS and its superset TS and that's not an accident. They're perfectly productive. My annoyance with JS is almost entirely to do with Node, otherwise I prefer JS to Python, for example.

Re: Pipe Operator (|>) For JavaScript

#120

Post by nightpool »

BigJono wrote: post #52
arp242 wrote: post #27

Is this: Object.keys(envars) .map(envar => `${envar}=${envars[envar]}`) .join(' ') |> `$ ${%}` |> chalk.dim(%, 'node', args.join(' ')) |> console.log(%); Really better than: console.log(chalk.dim( `$ ${Object.keys(envars) .map(envar => `${envar}=${envars[envar]}`) .join(' ') }`, 'node', args.join(' ') )); That's the real-world example they have (I reformatted the second one slightly, because it looks better to me). N…

TC39 proposals often have rubbish real world examples that should never see the light of day in a JS codebase. It makes me really question the judgement of the people that are working on this language, and it explains how some of the shittier proposals manage to slip in and why the good ones are misused all over the place in every real world codebase when this is the kind of guidance devs have on where to use fancy n…

> TC39 proposals often have rubbish real world examples that should never see the light of day in a JS codebase.

This example was literally taken directly from real-world code in the React codebase (a script to call jest-cli). While you're correct that there are probably a lot of clearer and more readable ways to write this snippet, the fact of the matter remains that people write code exactly like these "real world examples" all of the time.

Post reply on HN