Callback in javascript

Shreyesh kolhe

January 18, 2026 June 23, 2026

Callback Hell in JavaScript - A Deep Dive

Hey everyone! Welcome back to another episode of learning JavaScript the fun way. Today we're going to talk about something that every JavaScript developer has faced at some point - CALLBACKS. Yes, callbacks can be both a blessing and a curse.

So let's break it down into two parts:

The Good Part - Why callbacks are powerful
The Bad Part - Callback Hell & Inversion of Control

Let's dive in!

PART 1: The Good Part of Callbacks

JavaScript is a synchronous single-threaded language. It has just one call stack and can execute one thing at a time. Remember this golden rule:

"Time, tide and JavaScript waits for none!"

Let's see a simple example:

console.log("Namaste");
console.log("JavaScript");
console.log("Season 2");

OUTPUT:
Namaste
JavaScript
Season 2

JavaScript just prints these one after another. Super fast. No waiting.

But what if we NEED to wait for something? Suppose we want to print "JavaScript" after 5 seconds?

Here comes the HERO of our story - CALLBACKS!

// Using callback with setTimeout
setTimeout(function() {
    console.log("JavaScript");
}, 5000);

OUTPUT: (after 5 seconds)
JavaScript

See what happened here? We wrapped our code inside a callback function and passed it to setTimeout. Now it's the JOB of setTimeout to execute this callback after 5 seconds.

This is the POWER of callbacks - we can do asynchronous things in JavaScript!

PART 2: A Real World Example - E-commerce

Supposed we are building an e-commerce website. You know e-commerce can't exist without a cart, right? So let's create one:

const cart = ["shoes", "pants", "kurta"];
console.log(cart);

OUTPUT:
["shoes", "pants", "kurta"]

Now how does e-commerce work?

First, we CREATE an ORDER
Then, we PROCEED TO PAYMENT

There's a dependency here - we can only pay AFTER the order is created. How do we handle this with callbacks?

// The callback pattern for dependent async operations
api.createOrder(cart, function() {
    api.proceedToPayment();
});

OUTPUT:
Order Created Successfully!
Proceeding to Payment...
Payment Done!

What's happening here?

We pass a callback function to createOrder API
createOrder will create the order first
Then it will CALL BACK our function
And proceed to payment happens!

Beautiful, isn't it? But wait... things can get ugly.

PART 3: THE BAD PART - Callback Hell

Now suppose after payment, we need to:

Show order summary
Update the wallet

How would we write this? Watch closely...

api.createOrder(cart, function() {
    api.proceedToPayment(function() {
        api.showOrderSummary(function() {
            api.updateWallet(function() {
                // More nested callbacks...
            });
        });
    });
});

OUTPUT:
Order Created!
Payment Successful!
Order Summary Displayed!
Wallet Updated!

Do you see the problem?

This is called CALLBACK HELL! Also known as the "Pyramid of Doom"

Look at how our code is growing HORIZONTALLY instead of VERTICALLY. One callback inside another, inside another, inside another...

This type of code structure is:

Very hard to read
Very hard to maintain
Debugging becomes a nightmare
Trust me, I've seen this in production code at big companies!

The code looks like a pyramid or a Christmas tree turned sideways:

api.createOrder(cart, function() {
    api.proceedToPayment(function() {
        api.showOrderSummary(function() {
            api.updateWallet(function() {
                api.sendEmail(function() {
                    api.updateAnalytics(function() {
                        // And it goes on...
                    });
                });
            });
        });
    });
});

OUTPUT:
Order Created!
Payment Done!
Summary Shown!
Wallet Updated!
Email Sent!
Analytics Updated!
// Imagine debugging this nightmare!

PART 4: Inversion of Control

function fetchData(callback) {
  setTimeout(() => {
    callback("Data loaded");
  }, 1000);
}

fetchData((msg) => {
  console.log(msg);
});

You don’t decide when callback runs, that is Inversion of control

Now here's the MOST IMPORTANT part. Pay close attention!

Look at this code again:

api.createOrder(cart, function() {
    api.proceedToPayment(); // This is IMPORTANT code!
});

OUTPUT:
// We EXPECT this:
Order Created!
Payment Done!

// But what if createOrder has bugs?
// Payment might NEVER happen!
// Or Payment might happen TWICE!

What did we do here?

We GAVE our callback function to createOrder API. Now we're sitting back, relaxed, BLINDLY TRUSTING that createOrder will:

Create the order properly
Call our callback function

But wait... this is RISKY! Very very risky!

Why?

What if createOrder was written by some other developer?
What if there are bugs in createOrder?
What if our callback is NEVER called?
What if our callback is called TWICE? (Payment happens twice!)
We have NO CONTROL over when or how our callback gets executed!

This is called INVERSION OF CONTROL.

We literally handed over the control of our important code (proceed to payment) to some other function. We're blindly trusting it. And that's dangerous!

Quick Recap

THE GOOD:

Callbacks are a powerful way to handle async operations
Asynchronous programming in JavaScript exists BECAUSE callbacks exist
We can execute code at a later point in time

THE BAD:

1. CALLBACK HELL (Pyramid of Doom)

Callback inside callback inside callback
Code grows horizontally
Unmaintainable and hard to read

2. INVERSION OF CONTROL

We lose control of our code
We blindly trust other functions to call our callback
Risky for important operations like payments

Code Examples to Try

Example 1: Simple callback

function downloadFile(url, callback) {
    console.log("Downloading from: " + url);
    setTimeout(function() {
        console.log("Download complete!");
        callback("file-data");
    }, 2000);
}

downloadFile("https://example.com/file", function(data) {
    console.log("Got the data: " + data);
});

OUTPUT:
Downloading from: https://example.com/file
// after 2 seconds...
Download complete!
Got the data: file-data

Example 2: Callback Hell in action (DON'T DO THIS!)

function step1(callback) {
    setTimeout(() => { console.log("Step 1 done"); callback(); }, 1000);
}
function step2(callback) {
    setTimeout(() => { console.log("Step 2 done"); callback(); }, 1000);
}
function step3(callback) {
    setTimeout(() => { console.log("Step 3 done"); callback(); }, 1000);
}
function step4(callback) {
    setTimeout(() => { console.log("Step 4 done"); callback(); }, 1000);
}

// The Callback Hell way (BAD!)
step1(function() {
    step2(function() {
        step3(function() {
            step4(function() {
                console.log("All steps completed!");
            });
        });
    });
});

OUTPUT: (each line appears after 1 second)
Step 1 done
Step 2 done
Step 3 done
Step 4 done
All steps completed!

What's Next?

So how do we solve these problems? The answer is PROMISES!

Promises help us write cleaner async code and give us back the control. But that's a story for another blog post!

Keep coding, keep learning!

Episode - Callbacks in JavaScript — The Complete Guide

Hey everyone! Welcome back to Namaste JavaScript. Today we are going to study one of the most fundamental and important concepts in JavaScript — Callbacks!

Callbacks are the foundation of asynchronous JavaScript. Before Promises, before async/await — there were callbacks. If you want to truly understand JavaScript, you MUST understand callbacks first!

What we will cover:

What is a Callback Function?
Synchronous Callbacks
Asynchronous Callbacks
How JavaScript Handles Async — The Big Picture
Real-World Use Cases
Callback Hell (Pyramid of Doom)
Inversion of Control — The Hidden Problem
How to Escape Callback Hell
Famous Interview Questions

What is a Callback Function?

A callback is simply a function passed as an argument to another function, and that function is expected to call it back at some point later.

Simple Definition:
===================

function greet(name, callback) {
    console.log("Hello, " + name);
    callback();  // "Call me back" after greeting!
}

function sayBye() {
    console.log("Goodbye!");
}

greet("Shreyesh", sayBye);

OUTPUT:
Hello, Shreyesh
Goodbye!

// sayBye is passed as an argument → it is a CALLBACK function.
// greet calls it back when it is ready.

Key Insight:
=============

In JavaScript, functions are FIRST-CLASS CITIZENS.
This means functions can be:
  ✅ Assigned to variables
  ✅ Passed as arguments to other functions ← THIS is a callback!
  ✅ Returned from other functions

const fn = function() { console.log("I'm a function!"); };
setTimeout(fn, 1000);  // fn passed as callback to setTimeout!

Synchronous Callbacks

A synchronous callback is executed immediately inside the function it is passed to — no delay, no async, runs in order!

// Example 1: forEach — synchronous callback
const fruits = ["apple", "banana", "mango"];

fruits.forEach(function(fruit) {
    console.log(fruit);  // Called immediately, one by one
});

OUTPUT:
apple
banana
mango

// Example 2: map — synchronous callback
const numbers = [1, 2, 3, 4, 5];

const doubled = numbers.map(function(n) {
    return n * 2;  // Callback runs immediately for each item
});

console.log(doubled);

OUTPUT:
[2, 4, 6, 8, 10]

// Example 3: filter — synchronous callback
const scores = [45, 82, 33, 91, 60];

const passed = scores.filter(function(score) {
    return score >= 60;  // Keep only scores >= 60
});

console.log(passed);

OUTPUT:
[82, 91, 60]

// Example 4: sort — synchronous callback
const names = ["Zara", "Arjun", "Priya", "Shreyesh"];

names.sort(function(a, b) {
    return a.localeCompare(b);  // Alphabetical sort
});

console.log(names);

OUTPUT:
["Arjun", "Priya", "Shreyesh", "Zara"]

Synchronous Callbacks — What happens in memory:
================================================

Call Stack:
  main()
    → forEach()
        → callback("apple")   ← runs to completion
        → callback("banana")  ← runs to completion
        → callback("mango")   ← runs to completion
    ← forEach returns
  ← main() done

Everything happens in ORDER, one after another.
No jumping around, no waiting.

Asynchronous Callbacks

An asynchronous callback is NOT executed immediately. It is scheduled to run later — after a timer, after a network request, after a user event!

// Example: setTimeout — asynchronous callback
console.log("Start");

setTimeout(function() {
    console.log("I run after 2 seconds!");  // Async callback
}, 2000);

console.log("End");

OUTPUT:
Start
End
I run after 2 seconds!    ← runs AFTER 2 seconds

// "End" prints BEFORE the setTimeout callback!
// JavaScript does NOT wait for setTimeout.
// It registers the callback and moves on immediately.

Why does JavaScript NOT wait?
==============================

JavaScript is SINGLE-THREADED.
It has only ONE call stack — it can do only ONE thing at a time.

If JavaScript waited 2 seconds for setTimeout,
the entire page would FREEZE for 2 seconds!
No clicks, no scrolling, nothing would work.

So JavaScript says:
"I'll note this timer down. Web API will handle it.
 You (the main thread) keep working.
 When timer is done, I'll put the callback in the queue."

This is the POWER of asynchronous callbacks!

How JavaScript Handles Async — The Big Picture

JavaScript Runtime Components:
================================

┌─────────────────────────────────────────────────────────┐
│                  JAVASCRIPT ENGINE                      │
│                                                         │
│   ┌─────────────┐        ┌─────────────────────────┐   │
│   │  Call Stack │        │       Heap               │   │
│   │             │        │  (memory allocation)     │   │
│   │  main()     │        │                         │   │
│   │  callback() │        │                         │   │
│   └─────────────┘        └─────────────────────────┘   │
└─────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────┐
│                    WEB APIs (Browser)                   │
│                                                         │
│   setTimeout / setInterval                              │
│   fetch / XMLHttpRequest                                │
│   DOM Event Listeners                                   │
│   Geolocation, FileReader...                            │
└─────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────┐
│               CALLBACK QUEUE (Task Queue)               │
│                                                         │
│   [callback1] → [callback2] → [callback3]               │
│   Waiting to get pushed to Call Stack                   │
└─────────────────────────────────────────────────────────┘

              ↑
         EVENT LOOP
   (checks: is Call Stack empty?
    if yes → push next callback from queue)

Step-by-step — What happens with setTimeout:
=============================================

console.log("Start");        // Step 1
setTimeout(cb, 2000);        // Step 2
console.log("End");          // Step 3
// [2000ms passes...]
// cb() executes                Step 4

Step 1: "Start" → pushed to Call Stack → executes → removed
Step 2: setTimeout() → pushed to Call Stack
        → Web API registers the 2000ms timer
        → setTimeout() removed from Call Stack (Web API takes over)
Step 3: "End" → pushed to Call Stack → executes → removed
Step 4: 2000ms later → Web API pushes cb() into Callback Queue
        → Event Loop sees: Call Stack is empty!
        → Event Loop pushes cb() into Call Stack
        → cb() executes → "I run after 2 seconds!"

Real-World Use Cases of Callbacks

Event Handlers (click, keydown, scroll)
setTimeout and setInterval (timers)
Reading Files in Node.js (fs.readFile)
Making API/Network Requests
Array methods (map, filter, reduce, forEach, sort)
Database queries (older style)
Animation frames (requestAnimationFrame)

Use Case 1: Event Handlers

// Callback registered for a future user action
const btn = document.getElementById("myBtn");

btn.addEventListener("click", function() {
    // This callback runs ONLY when user clicks the button
    console.log("Button was clicked!");
});

// JavaScript doesn't wait here.
// It registers the callback and moves on.
// When user clicks → browser puts callback in queue → runs!

// Arrow function version
btn.addEventListener("click", () => {
    console.log("Clicked with arrow function!");
});

Use Case 2: setInterval — Repeating Callbacks

// Callback runs every 1 second
let count = 0;

const intervalId = setInterval(function() {
    count++;
    console.log("Count:", count);

    if (count === 5) {
        clearInterval(intervalId);  // Stop after 5 runs!
        console.log("Timer stopped!");
    }
}, 1000);

OUTPUT (one per second):
Count: 1
Count: 2
Count: 3
Count: 4
Count: 5
Timer stopped!

// Without clearInterval → runs FOREVER → memory leak!

Use Case 3: Node.js File System (fs.readFile)

// Reading a file — classic callback pattern in Node.js
const fs = require("fs");

console.log("Before readFile");

fs.readFile("./data.txt", "utf8", function(err, data) {
    // This callback runs AFTER the file is read!
    if (err) {
        console.log("Error reading file:", err);
        return;
    }
    console.log("File contents:", data);
});

console.log("After readFile");

OUTPUT:
Before readFile
After readFile
File contents: [content of data.txt]

// "After readFile" prints BEFORE the file is read!
// Because readFile is async — it doesn't block the thread.
// The callback runs after the OS finishes reading the file.

// Error-First Callback Pattern:
// Node.js callbacks always follow: function(err, data)
// First argument is ALWAYS the error (null if no error)
// This is the Node.js convention — ALWAYS check err first!

Use Case 4: Simulating an API Call

// Real-world: fetching user data asynchronously
function getUserData(userId, callback) {
    console.log("Fetching user data...");

    setTimeout(function() {
        // Simulating API response after 1 second
        const user = { id: userId, name: "Shreyesh", age: 25 };

        // Error-first callback pattern
        callback(null, user);
    }, 1000);
}

getUserData(101, function(err, user) {
    if (err) {
        console.log("Error:", err);
        return;
    }
    console.log("Got user:", user);
});

OUTPUT:
Fetching user data...
Got user: { id: 101, name: "Shreyesh", age: 25 }   ← after 1 second

Use Case 5: requestAnimationFrame — Smooth Animations

// Callback runs before the browser repaints (~60fps)
let position = 0;
const box = document.getElementById("box");

function animate() {
    position += 2;
    box.style.left = position + "px";

    if (position < 500) {
        requestAnimationFrame(animate);  // Callback calls itself!
    }
}

requestAnimationFrame(animate);

// Browser calls 'animate' ~60 times per second
// Smooth, hardware-accelerated animation
// MUCH better than setInterval for animations!

Callback Hell — The Pyramid of Doom!

When you need to do async operations one after another (sequential), callbacks start nesting inside each other. This creates what's called Callback Hell — also known as the Pyramid of Doom!

Imagine: Get User → Get User's Orders → Get Order Details → Send Email

// ❌ CALLBACK HELL
getUser(userId, function(err, user) {
    if (err) return handleError(err);

    getOrders(user.id, function(err, orders) {
        if (err) return handleError(err);

        getOrderDetails(orders[0].id, function(err, details) {
            if (err) return handleError(err);

            sendConfirmationEmail(user.email, details, function(err, result) {
                if (err) return handleError(err);

                updateOrderStatus(details.id, "confirmed", function(err, status) {
                    if (err) return handleError(err);

                    console.log("All done!", status);
                    // Imagine MORE nesting here... 😱
                });
            });
        });
    });
});

Visual — Why it's called "Pyramid of Doom":
============================================

getData(function(a) {
    getMoreData(a, function(b) {
        getEvenMoreData(b, function(c) {
            getAndMoreData(c, function(d) {
                getFinalData(d, function(e) {
                    // Here we are — at the bottom of the pyramid!
                    console.log(e);
                });            ↑
            });            ↑
        });            ↑
    });            ↑
});            ↑

See how the code goes to the right? → PYRAMID!
This is Callback Hell!

Problems with Callback Hell:
==============================

1. READABILITY: Code is nearly impossible to read or follow
2. DEBUGGING: Tracking which callback failed is very hard
3. ERROR HANDLING: Must handle errors in EVERY callback separately
4. MAINTAINABILITY: Adding a new step means restructuring everything
5. TRUST ISSUES: You don't control when/how the callback is called

Inversion of Control — The HIDDEN Problem with Callbacks!

Callback Hell is about readability. But there is a much deeper problem with callbacks — Inversion of Control. This is the real danger!

What is Inversion of Control?
==============================

When you pass a callback to a third-party function,
you are giving CONTROL of your code to someone else!

You are saying:
"Here is my callback. YOU decide when to call it,
 how many times, with what arguments."

You have LOST CONTROL of your own code!

Real-World Example — Payment Gateway:
========================================

// You are building a checkout flow
// You use a third-party payment SDK

thirdPartyPaymentSDK.processPayment(orderDetails, function() {
    // Your callback — fires when payment is done
    markOrderAsConfirmed();     // Update order in DB
    sendEmailToUser();          // Send confirmation email
    deductFromInventory();      // Reduce stock count
});

// 🚨 TRUST ISSUES:
// What if the third-party SDK has a bug and calls your
// callback TWICE? → Order confirmed twice, email sent twice!

// What if it never calls your callback?
// → Order is stuck forever, user is charged but no confirmation!

// What if it calls it too early (before payment is actually done)?
// → Order confirmed but money not received!

// What if it passes wrong arguments?
// → Your callback receives garbage data!

// You have NO control over any of this!
// This is INVERSION OF CONTROL!

The 5 Trust Problems with Callbacks:
======================================

1. Called too early       → before operation completes
2. Called too late        → or never called at all
3. Called too many times  → callback fires multiple times
4. Called with wrong args → bad data passed to your callback
5. Error swallowed        → exceptions thrown inside callback
                            might be silently ignored

These bugs are VERY hard to debug because they depend
on the third-party code — code you didn't write!

How to Escape Callback Hell

There are two main techniques to fix callback hell and inversion of control:

Fix 1: Named Functions (Flatten the Pyramid)

// ❌ Nested callbacks (hard to read)
getUser(userId, function(err, user) {
    getOrders(user.id, function(err, orders) {
        getOrderDetails(orders[0].id, function(err, details) {
            console.log(details);
        });
    });
});

// ✅ Named functions (flat, readable)
function handleDetails(err, details) {
    if (err) return console.log("Error:", err);
    console.log(details);
}

function handleOrders(err, orders) {
    if (err) return console.log("Error:", err);
    getOrderDetails(orders[0].id, handleDetails);
}

function handleUser(err, user) {
    if (err) return console.log("Error:", err);
    getOrders(user.id, handleOrders);
}

getUser(userId, handleUser);

// Same logic — but NOW it reads top to bottom!
// Each function has ONE job.
// Much easier to debug and test individually!

Fix 2: Promises (The Modern Solution)

// Promises RETURN CONTROL back to you!
// You decide what to do with the result — not the third party.

// ❌ Callback version
getUserData(userId, function(err, user) {
    getOrders(user.id, function(err, orders) {
        getOrderDetails(orders[0].id, function(err, details) {
            sendEmail(user.email, details, function(err) {
                console.log("Done!");
            });
        });
    });
});

// ✅ Promise version — flat chain!
getUserData(userId)
    .then(user => getOrders(user.id))
    .then(orders => getOrderDetails(orders[0].id))
    .then(details => sendEmail(details))
    .then(() => console.log("Done!"))
    .catch(err => console.log("Error:", err));  // ONE place for errors!

// WHY PROMISES ARE BETTER:
// - Flat chain instead of nested pyramid
// - ONE .catch() handles ALL errors
// - Callback called EXACTLY once (Promise guarantees!)
// - YOU control the .then() — not the third party

Fix 3: async / await (The Cleanest Solution)

// async/await makes async code look like synchronous code!

// ❌ Callback Hell
getUser(userId, function(err, user) {
    getOrders(user.id, function(err, orders) {
        getOrderDetails(orders[0].id, function(err, details) {
            console.log("Details:", details);
        });
    });
});

// ✅ async/await — reads like a story!
async function processOrder(userId) {
    try {
        const user    = await getUserData(userId);
        const orders  = await getOrders(user.id);
        const details = await getOrderDetails(orders[0].id);
        await sendEmail(user.email, details);
        console.log("Done!");
    } catch (err) {
        console.log("Error:", err);  // ONE catch for everything!
    }
}

processOrder(101);

// This is the EVOLUTION of callbacks:
// Callbacks → Promises → async/await
// Same concept underneath — async/await is just syntactic sugar
// over Promises. Promises are built on top of callbacks!

Evolution of Async JavaScript:
================================

Era 1 (ES5): Raw Callbacks
  getData(function(err, data) {
      // callback hell begins...
  });

Era 2 (ES6): Promises
  getData()
      .then(data => ...)
      .catch(err => ...);

Era 3 (ES2017): async/await
  const data = await getData();

Each era SOLVED the problems of the previous one.
But under the hood — it's all callbacks at the engine level!

Writing Your Own Callback-Based Functions

// Pattern: Error-First Callback (Node.js Style)
function divideNumbers(a, b, callback) {
    if (b === 0) {
        callback(new Error("Cannot divide by zero!"), null);
        return;
    }
    const result = a / b;
    callback(null, result);  // null = no error
}

divideNumbers(10, 2, function(err, result) {
    if (err) {
        console.log("Error:", err.message);
        return;
    }
    console.log("Result:", result);
});

divideNumbers(10, 0, function(err, result) {
    if (err) {
        console.log("Error:", err.message);
        return;
    }
    console.log("Result:", result);
});

OUTPUT:
Result: 5
Error: Cannot divide by zero!

RULES of Error-First Callbacks:
  1. First argument is ALWAYS the error (or null)
  2. Second argument is the successful result
  3. ALWAYS check for error first before using result
  4. ALWAYS call the callback — never leave it hanging
  5. Call the callback ONLY ONCE — never multiple times

// Pattern: Callback with multiple operations
function fetchDashboardData(userId, callback) {
    let completed = 0;
    const result = {};

    function checkDone() {
        completed++;
        if (completed === 3) {
            callback(null, result);  // All 3 done!
        }
    }

    // These run in PARALLEL, not sequential!
    getUser(userId, function(err, user) {
        if (err) return callback(err);
        result.user = user;
        checkDone();
    });

    getPosts(userId, function(err, posts) {
        if (err) return callback(err);
        result.posts = posts;
        checkDone();
    });

    getNotifications(userId, function(err, notifs) {
        if (err) return callback(err);
        result.notifications = notifs;
        checkDone();
    });
}

// This is essentially what Promise.all() does internally!

Interview Questions

Q1: What is a callback function in JavaScript?

"A callback function is a function passed as an argument to another function, which is then called inside the outer function at some point. Since JavaScript treats functions as first-class citizens — they can be passed as arguments — this pattern is very common. Callbacks can be synchronous (like forEach, map, filter) where they execute immediately, or asynchronous (like setTimeout, readFile, event listeners) where they execute after some delay or event."

Q2: What is the difference between synchronous and asynchronous callbacks?

"A synchronous callback is invoked immediately during the execution of the outer function — it runs in order, blocking the next line until it completes. Examples are forEach, map, filter, and sort. An asynchronous callback is NOT invoked immediately — it is scheduled to run later after a delay, an I/O operation, or a user event. Examples are setTimeout, fetch, fs.readFile, and addEventListener. Async callbacks don't block the main thread because the Web API or Node.js handles them in the background."

Q3: What is Callback Hell? How do you avoid it?

"Callback Hell is when multiple async operations are chained by nesting callbacks inside callbacks, creating deeply nested code that looks like a pyramid — this is also called the Pyramid of Doom. The code becomes hard to read, debug, and maintain, and error handling must be done in every level separately. We can avoid it by: using named functions to flatten the nesting, using Promises with .then() chains for readable sequential code, or using async/await which makes async code look synchronous and clean."

Q4: What is Inversion of Control in callbacks?

"Inversion of Control means that when you pass a callback to a third-party function, you give up control over when, how many times, and with what arguments your callback is called. This is dangerous because the third-party code could call your callback twice, never call it, call it too early, or call it with wrong data. Promises solve this problem — a Promise can only resolve or reject once, and the result is yours to handle with .then() on your own terms."

Q5: What is the error-first callback pattern?

"The error-first callback pattern is a Node.js convention where the first argument of every callback function is reserved for an error object and the second argument is the successful result. If the operation was successful, the first argument is null. If an error occurred, the first argument contains the Error object and the second is null. This forces the caller to check for errors before using the result — making error handling explicit and consistent across all async operations."

Q6: How does JavaScript handle asynchronous callbacks under the hood?

"JavaScript is single-threaded and has one Call Stack. When an async operation like setTimeout is encountered, the callback is handed off to the Web API (in the browser) or the C++ APIs (in Node.js). The main thread continues executing. When the async operation completes, the callback is placed in the Callback Queue (also called the Task Queue). The Event Loop continuously checks: 'Is the Call Stack empty?' If yes, it dequeues the next callback from the Callback Queue and pushes it onto the Call Stack for execution."

Q7: What is the difference between a callback and a higher-order function?

"A higher-order function is a function that either accepts another function as an argument OR returns a function. A callback is the function that is passed INTO a higher-order function. So in the expression array.map(callback) — map is the higher-order function, and the function passed to it is the callback. Every function that receives a callback is a higher-order function, but not every function passed as an argument is called a 'callback' — only those intended to be called back after some operation."

Q8: Why were Promises introduced if callbacks work?

"Promises were introduced to solve two major problems with callbacks: Callback Hell (deeply nested, hard to read code) and Inversion of Control (giving up control of your code to third parties). Promises allow you to chain .then() methods in a flat, readable structure instead of nesting. A Promise guarantees the callback is called exactly once, resolving the trust issue of callbacks being called multiple times or never. They also allow a single .catch() to handle errors from the entire chain, instead of handling errors in every callback separately."

Quick Recap

Concept	Description
Callback	A function passed as an argument to another function
First-Class Functions	Functions can be passed as arguments, returned, assigned to variables
Synchronous Callback	Runs immediately — forEach, map, filter, sort, reduce
Asynchronous Callback	Runs later — setTimeout, setInterval, readFile, addEventListener
Event Loop	Checks if Call Stack is empty, then pushes callback from queue
Callback Queue	Holds async callbacks waiting to enter the Call Stack
Callback Hell	Deeply nested callbacks — Pyramid of Doom — hard to read
Inversion of Control	Giving control of YOUR code to a third-party function
Error-First Pattern	callback(err, data) — Node.js convention, always check err first
Named Functions	Flatten pyramid by naming nested callbacks instead of inlining
Promises	Solves callback hell + inversion of control — flat .then() chain
async/await	Syntactic sugar over Promises — makes async code look sync

Key Points to Remember

Callback = function passed as argument to another function
Functions in JavaScript are first-class citizens — that's what enables callbacks
Synchronous callbacks run immediately — map, filter, forEach, sort
Asynchronous callbacks run later — setTimeout, events, file reads
JavaScript is single-threaded — callbacks allow async WITHOUT blocking
The Event Loop pushes callbacks from the Queue to the Call Stack when it's empty
Callback Hell = nested callbacks = hard to read = Pyramid of Doom
Inversion of Control = you give up control of when your code runs
Node.js uses the error-first callback pattern — always check err before data
Fix Callback Hell with named functions, Promises, or async/await
Callbacks → Promises → async/await = the evolution of async JavaScript
async/await is just syntactic sugar over Promises — Promises are built on callbacks
clearInterval to stop repeating callbacks — else it runs forever (memory leak!)
Use requestAnimationFrame instead of setInterval for smooth animations

Keep coding, keep learning! See you in the next one!

javascript

Shreyash Kolhe

Callback in javascript

Callback Hell in JavaScript - A Deep Dive

PART 1: The Good Part of Callbacks

PART 2: A Real World Example - E-commerce

PART 3: THE BAD PART - Callback Hell

PART 4: Inversion of Control

Quick Recap

Code Examples to Try

What's Next?

Episode - Callbacks in JavaScript — The Complete Guide

What is a Callback Function?

Synchronous Callbacks

Asynchronous Callbacks

How JavaScript Handles Async — The Big Picture

Real-World Use Cases of Callbacks

Use Case 1: Event Handlers

Use Case 2: setInterval — Repeating Callbacks

Use Case 3: Node.js File System (fs.readFile)

Use Case 4: Simulating an API Call

Use Case 5: requestAnimationFrame — Smooth Animations

Callback Hell — The Pyramid of Doom!

Inversion of Control — The HIDDEN Problem with Callbacks!

How to Escape Callback Hell

Fix 1: Named Functions (Flatten the Pyramid)

Fix 2: Promises (The Modern Solution)

Fix 3: async / await (The Cleanest Solution)

Writing Your Own Callback-Based Functions

Interview Questions

Quick Recap

Key Points to Remember

Post a Comment