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]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.
Without something like that, trying to add error handling to the things which may blow up would instantly turn it into gibberish. Every single function here can fail (the HTTP request could fail, the data returned could be unparseable as JSON, or not have the right format). We should be trying to make our languages encourage us to write code which can handle those errors naturally, rather than encouraging us to write fragile code.
Uncaught TypeError: Cannot read properties of undefined (reading 'periods') :3,$s/\./?./g