DEV Community

Discussion on: Simplify JavaScript Promises

Collapse
 
savagepixie profile image
SavagePixie

There are a couple of things that confuse me.

First, I guess I don't see what's the problem with callbacks. I mean, I know what people used to call callback hell and all that, but callbacks don't always generate it. In fact, functions as first class citizens is an amazing feature of JavaScript (map, filter and reduce being good examples of why). So I don't quite understand why not having to deal with callbacks would be a benefit.

Second is that you're already dealing with callbacks. You've got callbacks when you pass data through a then and when you handle errors. So I don't quite see what you're avoiding by using this method.

That's why I am a bit confused as to what you're supposed to be improving on. Mind you, I'm not saying that you're not getting anything out of it. I'm saying that I don't see what you're getting out of it that wouldn't be improved by ditching async/await altogether.

Bonus track: A lot of people do say that async/await makes your asynchronous code look synchronous. I find it an odd statement, though, as promise syntax looks a lot more like these synchronous snippets of code:

const transformNumbers = array => array
    .filter(isEven)
    .map(double)
    .map(addOne)
    .reduce(getMinMax, {
        min: Infinity,
        max: -Infinity
    })
const checkAdjacent = number => number 
    .toString()
    .split('')
    .some((x, i, a) => x == a[i - 1])

And more synchronous code would look like that if the TC39 guys finally implemented the pipeline operator.

What async/await does seem to do is to make asynchronous code look more imperative than promises. So maybe that's a thing you're getting by using your method?