3 ms·

I find callbacks and events much easier to understand then promises and futures. Example code: var req = get("https://news.ycombinator.com") req.onData = c

• Mitranim 9y ago
  For one operation, sure. It doesn't work when you want to compose multiple async operations, wait until all are finished, or race several of them to completion (e.g. useful operation competing against timeout). The purpose of promises/futures is this composability that allows you to get the order and timing of operations right.
  • z3t4 9y ago
    What if you want to abort, or take another path, depending on an error code ? With callbacks there's a convention that the first parameter is either null or an error.
    • Mitranim 9y ago
      That's what the mapping operators are for: `.mapResult` (same as `promise.then`), `.mapError` (same as `promise.catch`), or `.map`. The latter has an errback signature, like Node.js callbacks. They can also return new futures, transforming the result asynchronously. On top of that, error handling in promises/futures is much easier than in callbacks, as you can use one error handler for a chain of operations. Kinda like exceptions in synchronous code.
• a-saleh 9y ago
  Isn't callback hell referencing to the fact that you can't easily access the previous result of computation without nesting closures inside one another? It seems to me that first time I really avoided cb hell is when I started using async/await.
  • z3t4 9y ago
    var timeCreated = new Date(); button.onclick = function buttonClicked(clickEvent) { var timeClicked = new Date(); console.log("Button was created " + (timeClicked-timeCreated) + "ms ago"); } Lets say you have two functions: Jon from support, and Jane from billing. Both of them have access to the customer database. Now a customer calls, the customer hits 1 for support and Jon gets the call, while Jon is on the phone, another customer calls, hits 2 for billing and Jane gets the call. You can have a very complex setup using just functions, and some variables to keep track of things, maybe an array for implementing a call queue. You can choose when to run in serial, and when to run in parallel, and make a limit on how many calls that can run at any given time. And every possible error handled and managed. Promises, async/await and futures are only leaky abstractions that will just complicate things. They look nice for simple examples without any error handling, but when you want to do real world stuff you have to think about how they work behind the scenes.
    • Mitranim 9y ago
      It sounds like you're saying "explicit FSMs are strictly more powerful than promises/coroutines". Which is true. However, they're inherently difficult to program. In my view, the key to simplicity and correctness of programs is reducing the amount of states the program can possibly have. Isolating a piece of code into a blocking sequence seems like a fairly good way of doing it. Not sure what you mean by "simple examples without error handling". Just like normal synchronous code, promises and coroutines use exceptions, which have the nice property of composability: one catch for several statements/promises. So error handling is the same as in synchronous code. Now granted, there's a LOT of async/reactive problems where sequential abstractions like promises are irrelevant. GUI programming comes to mind, where you want the view to reflect some reactive state that changes in arbitrary order.
• romanovcode 9y ago
  Callback hell does not exist in modern javascript because you have async/await.