3 ms·

The "problems with callbacks" section of this is loaded with FUD. I mean, the actual problems they list are almost all minor or easily solvable. 1. Repetitive

The "problems with callbacks" section of this is loaded with FUD. I mean, the actual problems they list are almost all minor or easily solvable. 1. Repetitive error-handling, because you usually just want to pass it along. Maybe. Or maybe not. Forcing you to actually think about how you want to handle each error might be too cautious, but it's defensible -- especially in the context that async stuff is generally I/O related, so it's more likely than regular method invocation to need a close or a cleanup or a rollback in an error case. 2. The possibility for introducing error by forgetting to return from an error-handling callback pass-along. This is trivially catchable with a linter. (Eslint has a callback-return rule for this purpose.) 3. The idea that callbacks might be called multiple times. When that happens, it's not some weird case where maybe your callback needs to be prepared for multiple invocations, it's just a bug in the function you're calling. It should never happen with solid library code. 4. That the error parameter of a callback might be any kind of falsey value. This is true, but not a problem. Don't test for null or false, test for falseyness. As much as people talk about "callback hell," it's never clear to me what problems they actually think they're having. It seems that as often as not, it's just a visceral dislike of indentation.

amasad 10y ago
>As much as people talk about "callback hell," it's never clear to me what problems they actually think they're having. It seems that as often as not, it's just a visceral dislike of indentation. It's surprisingly hard to articulate the problems. It's one of those things that you can experience but hard to explain. I tried to explain it[1] by going through the example of implement a vending machine[2] in various concurrency patterns in JS. Starting with callbacks and ending with async/await. I still don't think I did a great job. [1] http://amasad.me/2015/10/31/javascript-async-functions-for-easier-concurrent-programming/ http://amasad.me/2015/10/31/javascript-async-functions-for-e... [2]: The vending machine example is inspired Tony Hoare's examples in the CSP book http://lass.cs.umass.edu/~shenoy/courses/summer04/readings/Hoare.pdf http://lass.cs.umass.edu/~shenoy/courses/summer04/readings/H...
danneu 10y ago
Most examples of callback hell on blogs and forum comments are just linear pyramids where each callback neatly waterfalls into the next. They are manageable but ugly which I think is why it's common to dismiss promises/await as cosmetic. In practice, callbacks become a problem when you need conditional async logic. Like if you have your simple callback pyramid but want to fork the chain at some level and merge it back at the end. What would've been a basic if-condition with promises/await is often an invasive change with callbacks where your only tool is to extract and rewrite logic into helper functions. A simple conceptual change easily blossoms into heavy indirection where taming the complexity becomes an engineering feat. At the end of the day, we all have different appetites for trade-offs.
- mkozlows 10y ago
  That's definitely a better example, yeah. I think that it's a very manageable problem -- if your functions are small and compositional in the first place, you're not going to be refactoring your 100-line magnum opus in a major way when you introduce a new conditional bit -- but that's definitely at least a problem that rings true to me in the way that so many "callback hell" complaints don't.

amasad 10y ago

>As much as people talk about "callback hell," it's never clear to me what problems they actually think they're having. It seems that as often as not, it's just a visceral dislike of indentation. It's surprisingly hard to articulate the problems. It's one of those things that you can experience but hard to explain. I tried to explain it[1] by going through the example of implement a vending machine[2] in various concurrency patterns in JS. Starting with callbacks and ending with async/await. I still don't think I did a great job. [1] http://amasad.me/2015/10/31/javascript-async-functions-for-easier-concurrent-programming/ http://amasad.me/2015/10/31/javascript-async-functions-for-e... [2]: The vending machine example is inspired Tony Hoare's examples in the CSP book http://lass.cs.umass.edu/~shenoy/courses/summer04/readings/Hoare.pdf http://lass.cs.umass.edu/~shenoy/courses/summer04/readings/H...

danneu 10y ago

Most examples of callback hell on blogs and forum comments are just linear pyramids where each callback neatly waterfalls into the next. They are manageable but ugly which I think is why it's common to dismiss promises/await as cosmetic. In practice, callbacks become a problem when you need conditional async logic. Like if you have your simple callback pyramid but want to fork the chain at some level and merge it back at the end. What would've been a basic if-condition with promises/await is often an invasive change with callbacks where your only tool is to extract and rewrite logic into helper functions. A simple conceptual change easily blossoms into heavy indirection where taming the complexity becomes an engineering feat. At the end of the day, we all have different appetites for trade-offs.

mkozlows 10y ago
That's definitely a better example, yeah. I think that it's a very manageable problem -- if your functions are small and compositional in the first place, you're not going to be refactoring your 100-line magnum opus in a major way when you introduce a new conditional bit -- but that's definitely at least a problem that rings true to me in the way that so many "callback hell" complaints don't.