On: Babel 7.5

[frabert]

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.

[dmitriid → frabert]

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

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

[Klathmon → dmitriid]

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.

[_v7gu → Klathmon]

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.

[Klathmon → _v7gu]

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.

[spion → _v7gu]

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.

[_v7gu → spion]

_.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.

[dmitriid → Klathmon]

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

[darepublic → dmitriid]

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

[dmitriid → darepublic]

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

[omegaworks → frabert]

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.

[adrusi → omegaworks]

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.

[omegaworks → adrusi]

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: