Ask HN: Is callback hell exaggerated?

It wasn&#x27;t really a problem with JS before 2010 because JS wasn&#x27;t used for servers. UI programming is usually event-driven, and rarely has long chains of asynchronous operations (outside of complicated programmer-defined animations, which few people are using). It became a problem with Node because suddenly folks are making lots of mutually-dependent network, filesystem, and database queries, all of which require a callback.<p>Even then, I think it&#x27;s a bit overstated - people were writing event-driven servers in C++ before Javascript was even invented. I do think that being able to use semicolons to sequence two statements is a lot more concise than nesting a chain of closures, though.

So, I think an example here will help you understand.<p>Let&#x27;s use NodeJS with Express and with pg-node. Let&#x27;s say you have a database.<p><pre><code> 1. You define an Express handler to handle a get request. 2. In that handler, you connect to a database, which takes a callback 3. You create a query on that connection, this takes a callback. 4. You then write a function that feeds the query result rows into a CSV exporter, which takes a callback (because of course it does). </code></pre> You now have a pyramid something like 5 levels deep. Callback hell is in fact a thing.<p>However, I&#x27;ve found that pipeline of promises almost completely solve that problem.

It&#x27;s a real problem, but so is promise-chain hell, and bound-event hell, and coroutine hell, and multithread hell, etc etc.<p>It&#x27;s not black and white, and no library is going to solve all the issues. A pragmatic JS engineer is going to have to use many different tools in their toolbelt on a routine basis, it&#x27;s just a matter of choosing the right tool for the job (which includes taking into account the environment you&#x27;re working in and the code that already exists).<p>But in general, in my experience, callback hell is often a sign of an upstream design-pattern issue. If the procedure you&#x27;re writing needs to call a series of 20 functions, in sequence, (and wait for them all to callback one after the other) you can probably implement it in a clean way that doesn&#x27;t require your code to move evermore to the right. Frameworks like Express (which passes around &quot;next&quot;), and Mocha (which passes around &quot;done&quot;) set great precedent of alternative ways to conceptualize those kind of issues. Achieving this in practice often means writing a combination of promises, callbacks, and other things.

Yeah, callback hell is not a real thing. People tend to dislike callbacks only when they don&#x27;t have much experience with them. I remember being like that myself. But there are a lot of problems that are inherently asynchronous and are much easier to solve with callbacks, than with anything else.

No.<p>It depends on how much of your business logic must be synchronous and how much it relies on asynchronous operations. It also depends on what you consider to be hellish.<p>async&#x2F;await is still cleaner than even a single promise, so you might as well use it.

It is a problem that is easily fixed. I like the fact that javascript allows you to write ugly code to make something work fast. When it works, you can refactor quickly by naming anonymous functions &#x2F; using Promises &#x2F; using whatever framework.<p>Here is my nodejs algorithm so far:<p><pre><code> - Code something ugly with 4-7 anonymous function levels - Realize I&#x27;m in callback hell - Refactor and make sure all functions have access to the variables they need. (Because the scope is often changed while refactoring) - Test - Repeat</code></pre>

Callbacks are successfully applied in lower-level languages. When a serial driver in Linux receives characters, generally at interrupt time, it invokes a callback in the TTY layer. You don&#x27;t hear kernel developers whining about &quot;callback hell&quot;. These C callbacks are just function pointers: any closure-like semantics is simulated by registering a pointer to data along with the function pointer, which is then passed in the callback call.

No it is not.

No.