While interesting, several of the examples don't account for errors, and are bad advice all around. You're better off using async functions or explicitly using/returning proper promises, or at least account for error conditions.
Care to elaborate some more? The author shows how to account for errors in scenarios where there are potential errors for example a network request, so im not sure where you see it being bad advice overall, care to clarify your point?
const Foo = {
async then (done) {
done(await request('https://foo.com'))
}
}
What happens when request throws an error (or the promise rejects)? ... in this case, there's no value to it.
But even then, the error handling completely breaks thenable conventions, which is a second function passed to then. In the end, Promises/thenables have a convention and this breaks it without providing more value than callbacks, while creating a context object construct.
const Foo = { async then (done) { done(await request('https://foo.com')) } } What happens when request throws an error (or the promise rejects)? ... in this case, there's no value to it.