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.