I don't know, it seems pretty clear to me. It beats doing

  let newScore = (await (await fetch(url)).json()).ID

and no, a myriad of intermediate variables is not always a nice alternative. This syntax gives a clear view of what happens to the data without having to untangle deeps expressions. I like it.

The page shows a much more clear and readable alternative, F# pipelines:

  let newScore = fetch(url)
    |> await
    |> r => r.json()
    |> await
    |> obj => obj.ID;

Wouldn't this be a lot easier to understand and work with?

    let newScore = await fetch(url)
      .then(r => r.json())
      .then(obj => obj.ID)

I think another problem is that these are just examples that aren't necessarily representative of real-life use cases but more just try to show all the different ways of using the syntax in one small chunk.

That example is wrapped perfectly, so it seems a bit unneeded. A more complex example would be

    // helper for method calls in pipes
    const _ = new Proxy({}, {get(_i, c) { return (...args) => e => e[c](...args)}})

    document
      .querySelectorAll('.requestedIds')
      |> Array.from
      |> _.map(el => fetch(`//address/${el.value}`))
      |> Promise.all
      |> await
      |> _.map(re => re.json())
      |> Object.fromEntries
      |> processResponse

In this case, there is both methods and function calls, which complicates reading quite a bit. Converted to pipes, it's simply from top to bottom.

But reading it like this I greatly prefer the F# style since it reads a lot more straightforward and easy to understand what is happening.

That being said, can't you abuse the promise syntax to get something very similar right now? Since `.then` will wrap a non-promise return value in a promise, this would do the same as your example:

    Promise.resolve(document.querySelectorAll('.requestedIds'))
      .then(p => Array.from(p))
      .then(p => p.map(el => fetch(`//address/${el.value}`)))
      .then(p => Promise.all(p))
      .then(p => p.map(re => re.json())
      .then(p => Object.fromEntries(p))
      .then(p => processResponse(p))

But funnily enough, as I went to go write out that example, I realized that I have no idea what the hell is being passed into the `_.map` functions... Even me being lazy and using `p` as the variable name for each pipe, the version that writes it out is massively easier to understand in my opinion.

I'd like to see the type signature of that `_` construct.

It seems to me like the bind operator would've made the extra complexity unnecessary.

_.map is basically syntatic sugar for p => p.map, only written with today's javascript capabilities. I just tried to implement the proposed #. Dynamic access to methods doesn't yield very nice type signatures.

Yes, in this particular case `then` works better. Pipes are a very generic pattern though, and are quite useful when you have a chain of operations (whether those operations are async or not).

Hopefully there will be no issue adding a breakpoint to see the structure of obj, a common debugging necessity

Chrome dev tools let you put breakpoints inside promises, and debug promises in general. I guess they'll update the tools to let you set breakpoints inside pipes (at least I'm hoping so :) )

How does it read in your internal monologue? "await pound" doesn't convey a whole lot of semantic meaning to me.

I'm curious how others read it.

Perl programmers read "$_" as "it".

So you could read the expression above as "fetch url, then await it, then get its json then await it, then get its ID"

Although I don't know why a syntax needs to be verbally legible, seems like an odd requirement to me.

There's a reason why Pearl is considered a write-only language.

Programming languages typically opt for either verbal legibility or having their symbols represent some understood structural / visual cue (like an arrow, for example). There's nothing about the character "#" that indicates the directionality of the operation visually, so I assumed there was some verbal mapping that I wasn't familiar with. ("Hash", "pound", "number", etc).

Typically programming languages are used to communicate procedures in ways that would allow human people with a similar set of cultural references to understand what is going on by reading it. Having verbal legibility allows people who know the language to explain very quickly to new people what is meant by a given symbol. Otherwise why #? It could be any symbol.

Communicating meaning for humans might not be the intent for javascript moving forward, given where WASM and transpilation is headed, so :shrug:

You should pity people debugging very different constructs than this.

This is clear as day, and I haven't even read the proposal...

I never said understanding, I said debugging. There are 4 implicit objects here (discounting proxies and wrappers), so unless you know them by heart, you have now idea what's in there. Then of course most debuggers will consider that one line, so to debug, you will hall have to split it in several ones to have the right to know what's going on. Plus, now that you have done it, what ? You put them back as they were ?

That's also hoping your code map files and your browser work well together, which is often not the case. Transpiled code is always a pain to debug at one point or another.

And that's just one line, a code back "full of those" will let you do the dance again and again. A very slow dance at that, cause babel is not the fastest horse in town.

Finally I'll pray your intern doesn't have to do it. But we all have teams full of good programmers right ?

But that's wishful thinking, you could be wrong about what that code does.

Not really. There's no magic in the code, it's a pretty well established construct, used in other languages for decades...

The pipe operator has was introduced to R a few years ago. It is one of those things I miss the most in js.

Debugging is an issue though. I commonly find myself splitting up the pipes into section in order to inspect the results and find exceptions. Breakpoints and stepping through code is probably the features I most often struggle with.