Live data from Hacker News

Ask HN: Is callback hell exaggerated?

news.ycombinator.com

1–10 of 21 posts

Ask HN: Is callback hell exaggerated?

#1
I played around with just using callbacks as a test and it wasn't bad at all.

Most information on it seems to start off as a T.V. infomercial for some library. Don't suffer from callback hell, use X!

I can barely find anything on the internet about callback hell before 2010 to indicated that it was a real problem at all with javascript.

Re: Ask HN: Is callback hell exaggerated?

#2
It wasn't really a problem with JS before 2010 because JS wasn'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.

Even then, I think it'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.

Re: Ask HN: Is callback hell exaggerated?

#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.

Re: Ask HN: Is callback hell exaggerated?

#4
Yeah, callback hell is not a real thing. People tend to dislike callbacks only when they don'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.

Re: Ask HN: Is callback hell exaggerated?

#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 a callback (because of course it does).
You now have a pyramid something like 5 levels deep. Callback hell is in fact a thing.

However, I've found that pipeline of promises almost completely solve that problem.

Re: Ask HN: Is callback hell exaggerated?

#6

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.

Re: Ask HN: Is callback hell exaggerated?

#7

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){
      if(err) callback("error1")
      state.dbInstance=data
      state.dbInstance.query("someQuery",logic.bind(state,2))
    }
    
    if(step==2){
      if(err) callback("error2")
      csvExporter(data,logic.bind(state,3))
    }

    if(step==3){
      if(err) callback("error3")
      callback(data)
    }
  }
  logic()
}
Post reply on HN