Am I wrong in feeling that callback hell is a symptom of bad design? In what scenario are you making four server requests before you can do something on a webpage?
I like async/await more for it's brevity than utility.
I like async/await more for it's brevity than utility.
If you have two logical branches that share a downstream, now you have a fork with identical callbacks.
So reducing callback indentation comes at the expense of indirection. You're not changing the nesting at all. Usually just brooming stuff under the rug.
I think so, yes. Chaining together four consecutive web service requests might be a bad smell, but there are lots of other reasons to use async calls - waiting on a timeout, a worker, using IndexedDB, waiting on a user event or an animation, etc, etc.
In general if something can be done asynchronously it probably should be, so depending on the domain I'd say a lack of callbacks can be suspicious.
Callback hell isn't a symptom of bad design. It's what happens when you have a lot of async function calls. Flattening callback hell often just contributes to callback hell with indirection, making it even harder to follow.
But thankfully we have promises, now.
graphql points toward this