5 ms·
I affably don’t know how anyone considers the .then syntax to be any better than the original callback hell version. Especially if you want your error handlers
by matt-attack 7y ago
I affably don’t know how anyone considers the .then syntax to be any better than the original callback hell version. Especially if you want your error handlers to be unique and to affect the flow. Sorry but the common shared catch at the end doesn’t usually suffice in the code I write.
I find the async/await form he alludes to at the end to be the only form that improves upon the original callback version.
- stareatgoats 7y agoAgree. Async/await and promises get overly complex and riddled with conceptual challenges in anything but the most basic examples. I finally rolled my own async job queue library instead (using .then, granted). A few hundred loc, but conceptually clear, no callback hell, a tiny bit more verbose, but full control over error handling in each callback. Such a relief.
- franciscop 7y agoIt's not much more clear, but it is a standard, which has many advantages: - Learn how .then()/.catch() works once and it's the same for all libraries. - Can test against a common API. - Can combine operations easily like with Promise.all(), which was very difficult with callbacks. - Chaining is much better since you can return a promise within a promise, which allows for conditional promises. - No nesting/right shifting, keeping the structure flatter.
- matt-attack 7y agoasync/await has all of those same advantages plus more I believe (and I should add I agree with all of them).
- franciscop 7y agoAsync/await is syntax sugar on top of .then(); without the standardization of promises with .then(), async/await would have been A LOT harder to get cross projects. Ofc async/await is waaay better than .then(), but you were talking about async/await vs callbacks, and so my points :)