Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Is callback hell exaggerated?

news.ycombinator.com

Post reply on HN
Print view View original

11–20 of 21 posts

Re: Ask HN: Is callback hell exaggerated?

#11

Post by sleazebreeze »

tonyle wrote: post #7
angersock wrote: post #5

So, I think an example here will help you understand. Let's use NodeJS with Express and with pg-node. Let's say you have a database. 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…

I'm not sure when promises came to the javascript, but it seems weird that people would settle with callback hell for so long without even attempting to refactoring it. I mean if I didn't have the option of using promises, I would have probably written something like this. function handler(callback){ var state={}; function logic(step,err,data){ if(!step){ connectToDb("somedatabase",logic.bind(state,1)) } if(step==1){…

That looks like a very similar pattern that I've seen commonly used in Go. It makes for very clear code and explicit error handling. I kind of like it for the clarity, even if it isn't "elegant" or concise.

Re: Ask HN: Is callback hell exaggerated?

#12

Post by [deleted] »

tonyle wrote: post #7
angersock wrote: post #5

So, I think an example here will help you understand. Let's use NodeJS with Express and with pg-node. Let's say you have a database. 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…

I'm not sure when promises came to the javascript, but it seems weird that people would settle with callback hell for so long without even attempting to refactoring it. I mean if I didn't have the option of using promises, I would have probably written something like this. function handler(callback){ var state={}; function logic(step,err,data){ if(!step){ connectToDb("somedatabase",logic.bind(state,1)) } if(step==1){…

[deleted]

Re: Ask HN: Is callback hell exaggerated?

#13

Post by xyzzy123 »

tonyle wrote: post #7
angersock wrote: post #5

So, I think an example here will help you understand. Let's use NodeJS with Express and with pg-node. Let's say you have a database. 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…

I'm not sure when promises came to the javascript, but it seems weird that people would settle with callback hell for so long without even attempting to refactoring it. I mean if I didn't have the option of using promises, I would have probably written something like this. function handler(callback){ var state={}; function logic(step,err,data){ if(!step){ connectToDb("somedatabase",logic.bind(state,1)) } if(step==1){…

Did you mean return callback("error1") etc? Forgetting the return is a classic bug when you're in callback hell...

Re: Ask HN: Is callback hell exaggerated?

#14

Post by smt88 »

gravypod wrote: post #6
angersock wrote: post #5

So, I think an example here will help you understand. Let's use NodeJS with Express and with pg-node. Let's say you have a database. 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…

Promise frameworks do seem to lend well to this sort of problem and I'm excited to see these developed.

There are tons of promise libraries and most major frameworks either support promises or can be "promisified" easily

Re: Ask HN: Is callback hell exaggerated?

#15

Post by MalcolmDiggs »

It's a real problem, but so is promise-chain hell, and bound-event hell, and coroutine hell, and multithread hell, etc etc.

It'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's just a matter of choosing the right tool for the job (which includes taking into account the environment you're working in and the code that already exists).

But in general, in my experience, callback hell is often a sign of an upstream design-pattern issue. If the procedure you'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't require your code to move evermore to the right. Frameworks like Express (which passes around "next"), and Mocha (which passes around "done") 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.

Re: Ask HN: Is callback hell exaggerated?

#16

Post by nojvek »

smt88 wrote: post #3

No. 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. async/await is still cleaner than even a single promise, so you might as well use it.

Agree with this. Async await is just a lot cleaner syntax. The problem with callback hell is making sense of flow and handling the error at every step.

Promises certainly help but you also see abuse of then callback hell where rather than chaining, someone would nest the thens.async await is also great for debugging.

Re: Ask HN: Is callback hell exaggerated?

#17

Post by angersock »

xyzzy123 wrote: post #13
tonyle wrote: post #7

Earlier quoted context omitted.

I'm not sure when promises came to the javascript, but it seems weird that people would settle with callback hell for so long without even attempting to refactoring it. I mean if I didn't have the option of using promises, I would have probably written something like this. function handler(callback){ var state={}; function logic(step,err,data){ if(!step){ connectToDb("somedatabase",logic.bind(state,1)) } if(step==1){…

Did you mean return callback("error1") etc? Forgetting the return is a classic bug when you're in callback hell...

Yeeeeep.

I think the example and your reply neatly illustrate the problem.

Re: Ask HN: Is callback hell exaggerated?

#18

Post by antoineMoPa »

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 / using Promises / using whatever framework.

Here is my nodejs algorithm so far:

    - Code something ugly with 4-7 anonymous function levels
    - Realize I'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

Re: Ask HN: Is callback hell exaggerated?

#20

Post by kazinator »

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't hear kernel developers whining about "callback hell". 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.
Post reply on HN