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 :) )