Callback Patterns & Avoiding Callback Hell

What is a Callback?

A callback is a function that is passed as an argument to another function and is executed at a later time. Callbacks are one of the foundational patterns in JavaScript and are the basis for handling asynchronous operations. The name "callback" comes from the idea that you are providing a function to be "called back" when something happens -- when data arrives from a server, when a timer expires, when a user clicks a button, or when a file finishes reading.

Callbacks work because JavaScript treats functions as first-class citizens. This means functions can be assigned to variables, passed as arguments to other functions, returned from functions, and stored in data structures. This capability makes callbacks possible and is one of the most powerful features of the language.

// greet is a callback function passed to performAction
function greet(name) {
    console.log('Hello, ' + name + '!');
}

function farewell(name) {
    console.log('Goodbye, ' + name + '!');
}

function performAction(name, actionCallback) {
    console.log('Performing action for: ' + name);
    actionCallback(name); // Execute the callback
}

performAction('Alice', greet);    // "Performing action for: Alice" then "Hello, Alice!"
performAction('Bob', farewell);   // "Performing action for: Bob" then "Goodbye, Bob!"

In this example, greet and farewell are callback functions. They are not executed immediately when passed to performAction -- they are executed inside performAction when it decides to call them. This pattern gives the calling function control over when and how the callback is invoked.

Synchronous vs Asynchronous Callbacks

Callbacks can be either synchronous or asynchronous. Understanding the difference is crucial for writing correct JavaScript code.

Synchronous callbacks are executed immediately during the execution of the function they are passed to. The code after the function call does not run until the callback has completed. Array methods like forEach, map, filter, and reduce use synchronous callbacks.

const numbers = [1, 2, 3, 4, 5];

// forEach -- synchronous callback, runs immediately for each element
console.log('Before forEach');
numbers.forEach(function(num) {
    console.log('Processing: ' + num);
});
console.log('After forEach');
// Output order is guaranteed:
// "Before forEach"
// "Processing: 1"
// "Processing: 2"
// "Processing: 3"
// "Processing: 4"
// "Processing: 5"
// "After forEach"

// map -- synchronous callback that transforms each element
const doubled = numbers.map(function(num) {
    return num * 2;
});
console.log(doubled); // [2, 4, 6, 8, 10]

// filter -- synchronous callback that selects elements
const evens = numbers.filter(function(num) {
    return num % 2 === 0;
});
console.log(evens); // [2, 4]

// reduce -- synchronous callback that accumulates a result
const sum = numbers.reduce(function(accumulator, num) {
    return accumulator + num;
}, 0);
console.log(sum); // 15

Asynchronous callbacks are executed at a later time, after the current function has returned. The code after the function call continues to run while the asynchronous operation is in progress. Timer functions (setTimeout, setInterval), event listeners, and network requests use asynchronous callbacks.

console.log('Step 1: Start');

// setTimeout -- asynchronous, callback runs after delay
setTimeout(function() {
    console.log('Step 2: This runs after 2 seconds');
}, 2000);

console.log('Step 3: This runs immediately, before Step 2');

// Output order:
// "Step 1: Start"
// "Step 3: This runs immediately, before Step 2"
// (2 seconds later)
// "Step 2: This runs after 2 seconds"

The Error-First Callback Convention

In Node.js and many JavaScript libraries, callbacks follow the error-first convention (also called "Node-style callbacks"). The callback function receives an error object as its first argument. If the operation succeeded, the error is null and the result is passed as the second argument. If the operation failed, the error contains information about what went wrong.

// Simulating a database lookup with error-first callback
function findUserById(id, callback) {
    // Simulate async database query
    setTimeout(function() {
        if (typeof id !== 'number' || id < 1) {
            // Error case: call with error as first argument
            callback(new Error('Invalid user ID: ' + id), null);
            return;
        }

        // Simulated database of users
        const users = {
            1: { id: 1, name: 'Alice', email: 'alice@example.com' },
            2: { id: 2, name: 'Bob', email: 'bob@example.com' },
            3: { id: 3, name: 'Charlie', email: 'charlie@example.com' }
        };

        const user = users[id];

        if (!user) {
            // Error case: user not found
            callback(new Error('User not found with ID: ' + id), null);
            return;
        }

        // Success case: error is null, result is second argument
        callback(null, user);
    }, 500);
}

// Using the error-first callback
findUserById(2, function(error, user) {
    if (error) {
        console.error('Error:', error.message);
        return;
    }
    console.log('Found user:', user.name); // "Found user: Bob"
});

findUserById(99, function(error, user) {
    if (error) {
        console.error('Error:', error.message); // "Error: User not found with ID: 99"
        return;
    }
    console.log('Found user:', user.name);
});

Real-World Callback APIs

Callbacks are everywhere in JavaScript. Here are the most common real-world APIs that use callbacks:

Event Listeners

The addEventListener method is one of the most frequently used callback patterns in the browser. The callback function (called an event handler) executes every time the specified event occurs on the target element.

// Click event callback
const button = document.getElementById('submit-btn');

button.addEventListener('click', function(event) {
    event.preventDefault();
    console.log('Button clicked!');
    console.log('Click position: X=' + event.clientX + ', Y=' + event.clientY);
});

// Input event callback with debounce pattern
let debounceTimer;
const searchInput = document.getElementById('search');

searchInput.addEventListener('input', function(event) {
    clearTimeout(debounceTimer);
    debounceTimer = setTimeout(function() {
        console.log('Searching for: ' + event.target.value);
        // Perform search after user stops typing for 300ms
    }, 300);
});

// Multiple events on the same element
const form = document.getElementById('contact-form');

form.addEventListener('submit', function(event) {
    event.preventDefault();
    console.log('Form submitted');
});

form.addEventListener('reset', function() {
    console.log('Form reset');
});

Timer Functions

setTimeout and setInterval are built-in functions that accept callbacks to be executed after a delay or at regular intervals.

// setTimeout -- execute once after a delay
function showNotification(message) {
    console.log('Notification: ' + message);
}

const timerId = setTimeout(showNotification, 3000, 'Your session will expire soon');

// Cancel the timer before it fires
// clearTimeout(timerId);

// setInterval -- execute repeatedly at intervals
let count = 0;
const intervalId = setInterval(function() {
    count++;
    console.log('Tick #' + count);

    if (count >= 5) {
        clearInterval(intervalId);
        console.log('Timer stopped after 5 ticks');
    }
}, 1000);

Array Iteration Methods

Array methods that accept callbacks are among the most commonly used synchronous callback patterns. They provide a declarative way to work with collections.

const products = [
    { name: 'Laptop', price: 999, category: 'electronics' },
    { name: 'Book', price: 15, category: 'education' },
    { name: 'Headphones', price: 79, category: 'electronics' },
    { name: 'Notebook', price: 5, category: 'education' },
    { name: 'Monitor', price: 349, category: 'electronics' }
];

// filter -- select products over $50
const expensive = products.filter(function(product) {
    return product.price > 50;
});
console.log(expensive.length); // 3

// map -- extract just the names
const names = products.map(function(product) {
    return product.name;
});
console.log(names); // ["Laptop", "Book", "Headphones", "Notebook", "Monitor"]

// find -- get the first electronics product
const firstElectronic = products.find(function(product) {
    return product.category === 'electronics';
});
console.log(firstElectronic.name); // "Laptop"

// sort -- sort by price (ascending)
const sorted = [...products].sort(function(a, b) {
    return a.price - b.price;
});

// every and some -- test conditions
const allUnder1000 = products.every(function(product) {
    return product.price < 1000;
});
console.log(allUnder1000); // true

const hasEducation = products.some(function(product) {
    return product.category === 'education';
});
console.log(hasEducation); // true

Callback Hell: The Pyramid of Doom

When you have multiple asynchronous operations that depend on each other, you must nest callbacks inside callbacks. Each dependent operation adds another level of indentation, creating a shape that developers call the pyramid of doom or callback hell. This pattern makes code extremely difficult to read, maintain, debug, and extend.

// A realistic scenario: user authentication flow
// Each step depends on the result of the previous step

function authenticateUser(username, password, callback) {
    setTimeout(function() {
        if (username === 'admin' && password === 'secret') {
            callback(null, { userId: 1, token: 'abc123' });
        } else {
            callback(new Error('Invalid credentials'), null);
        }
    }, 500);
}

function getUserProfile(userId, callback) {
    setTimeout(function() {
        callback(null, { userId: userId, name: 'Admin User', role: 'admin' });
    }, 500);
}

function getUserPermissions(role, callback) {
    setTimeout(function() {
        callback(null, ['read', 'write', 'delete', 'admin']);
    }, 500);
}

function getNotifications(userId, callback) {
    setTimeout(function() {
        callback(null, [
            { id: 1, message: 'New comment on your post' },
            { id: 2, message: 'System update scheduled' }
        ]);
    }, 500);
}

function logActivity(userId, action, callback) {
    setTimeout(function() {
        callback(null, { logged: true, timestamp: new Date() });
    }, 300);
}

// THE PYRAMID OF DOOM -- each callback nests inside the previous
authenticateUser('admin', 'secret', function(err, auth) {
    if (err) {
        console.error('Auth failed:', err.message);
        return;
    }
    getUserProfile(auth.userId, function(err, profile) {
        if (err) {
            console.error('Profile failed:', err.message);
            return;
        }
        getUserPermissions(profile.role, function(err, permissions) {
            if (err) {
                console.error('Permissions failed:', err.message);
                return;
            }
            getNotifications(auth.userId, function(err, notifications) {
                if (err) {
                    console.error('Notifications failed:', err.message);
                    return;
                }
                logActivity(auth.userId, 'login', function(err, logResult) {
                    if (err) {
                        console.error('Logging failed:', err.message);
                        return;
                    }
                    // Finally we have everything we need
                    console.log('Welcome,', profile.name);
                    console.log('Permissions:', permissions);
                    console.log('Notifications:', notifications.length);
                    console.log('Activity logged at:', logResult.timestamp);
                });
            });
        });
    });
});

Problems with Callback Hell

Callback hell creates several specific problems that go beyond just "looking ugly":

• Readability -- Deep nesting makes the logical flow of the program hard to follow. You cannot scan the code top-to-bottom and understand what happens in order.
• Error handling -- Each callback must check for errors independently. It is easy to forget an error check, and there is no way to catch all errors in a single place. If an error occurs deep in the pyramid, unwinding the state is complex.
• Debugging -- Stack traces in nested callbacks are hard to interpret. Breakpoints must be set at multiple nesting levels. The asynchronous nature means the call stack does not show the logical chain of operations.
• Inversion of control -- When you pass a callback to a third-party function, you trust that function to call your callback correctly -- exactly once, with the right arguments, and at the right time. This trust can be violated, and you have no way to enforce it.
• Code duplication -- Error handling logic is repeated at every nesting level. If you want to add logging or retry logic, you must add it everywhere.
• Composition difficulty -- Running operations in parallel, racing between operations, or conditionally executing steps is extremely difficult with nested callbacks.

Solution 1: Named Functions

The simplest improvement is to extract anonymous callbacks into named functions. This flattens the pyramid, gives each step a descriptive name, and makes the code easier to follow and test individually.

// Extract each callback into a named function

function handleAuth(err, auth) {
    if (err) {
        console.error('Auth failed:', err.message);
        return;
    }
    // Store auth info for later use
    currentAuth = auth;
    getUserProfile(auth.userId, handleProfile);
}

function handleProfile(err, profile) {
    if (err) {
        console.error('Profile failed:', err.message);
        return;
    }
    currentProfile = profile;
    getUserPermissions(profile.role, handlePermissions);
}

function handlePermissions(err, permissions) {
    if (err) {
        console.error('Permissions failed:', err.message);
        return;
    }
    currentPermissions = permissions;
    getNotifications(currentAuth.userId, handleNotifications);
}

function handleNotifications(err, notifications) {
    if (err) {
        console.error('Notifications failed:', err.message);
        return;
    }
    logActivity(currentAuth.userId, 'login', function(err, logResult) {
        if (err) {
            console.error('Logging failed:', err.message);
            return;
        }
        displayDashboard(currentProfile, currentPermissions, notifications, logResult);
    });
}

function displayDashboard(profile, permissions, notifications, logResult) {
    console.log('Welcome,', profile.name);
    console.log('Permissions:', permissions);
    console.log('Notifications:', notifications.length);
    console.log('Activity logged at:', logResult.timestamp);
}

// Clean entry point
let currentAuth, currentProfile, currentPermissions;
authenticateUser('admin', 'secret', handleAuth);

Solution 2: Early Returns and Guard Clauses

When callbacks contain error checks followed by success logic, use early returns (guard clauses) to handle errors first and keep the success path at the lowest indentation level. This reduces nesting within each callback.

// Without early return -- error and success at same nesting
function processFile(filename, callback) {
    readFile(filename, function(err, content) {
        if (err) {
            callback(err, null);
        } else {
            parseContent(content, function(err, data) {
                if (err) {
                    callback(err, null);
                } else {
                    validateData(data, function(err, result) {
                        if (err) {
                            callback(err, null);
                        } else {
                            callback(null, result);
                        }
                    });
                }
            });
        }
    });
}

// With early returns -- cleaner, less nesting
function processFile(filename, callback) {
    readFile(filename, function(err, content) {
        if (err) return callback(err, null);

        parseContent(content, function(err, data) {
            if (err) return callback(err, null);

            validateData(data, function(err, result) {
                if (err) return callback(err, null);

                callback(null, result);
            });
        });
    });
}

Solution 3: Modularization

Break complex callback flows into smaller, reusable modules. Each module handles one aspect of the flow and can be tested independently. This approach follows the single responsibility principle.

// auth.js -- handles authentication logic
function loginFlow(username, password, onComplete) {
    authenticateUser(username, password, function(err, auth) {
        if (err) return onComplete(err, null);

        getUserProfile(auth.userId, function(err, profile) {
            if (err) return onComplete(err, null);

            onComplete(null, { auth: auth, profile: profile });
        });
    });
}

// permissions.js -- handles permission loading
function loadPermissions(profile, onComplete) {
    getUserPermissions(profile.role, function(err, permissions) {
        if (err) return onComplete(err, null);

        onComplete(null, permissions);
    });
}

// notifications.js -- handles notification loading
function loadNotifications(userId, onComplete) {
    getNotifications(userId, function(err, notifications) {
        if (err) return onComplete(err, null);

        onComplete(null, notifications);
    });
}

// app.js -- composes the modules
function initializeApp(username, password) {
    loginFlow(username, password, function(err, loginData) {
        if (err) {
            console.error('Login failed:', err.message);
            return;
        }

        loadPermissions(loginData.profile, function(err, permissions) {
            if (err) {
                console.error('Permissions failed:', err.message);
                return;
            }

            loadNotifications(loginData.auth.userId, function(err, notifications) {
                if (err) {
                    console.error('Notifications failed:', err.message);
                    return;
                }

                console.log('Welcome,', loginData.profile.name);
                console.log('Permissions:', permissions);
                console.log('Notifications:', notifications.length);
            });
        });
    });
}

initializeApp('admin', 'secret');

Transitioning from Callbacks to Promises

Promises provide a fundamentally better model for asynchronous programming. Instead of passing a callback into a function, the function returns a Promise object that represents the eventual completion or failure of the operation. This shifts control back to the caller and enables chaining, centralized error handling, and composition patterns that are impossible with plain callbacks.

Manual Promisification

To convert a callback-based function to a Promise-based one, wrap it in a new Promise. Call resolve on success and reject on failure.

// Original callback-based function
function findUserById(id, callback) {
    setTimeout(function() {
        if (id < 1) {
            callback(new Error('Invalid ID'), null);
            return;
        }
        const users = { 1: { name: 'Alice' }, 2: { name: 'Bob' } };
        const user = users[id];
        if (!user) {
            callback(new Error('User not found'), null);
            return;
        }
        callback(null, user);
    }, 500);
}

// Promisified version
function findUserByIdPromise(id) {
    return new Promise(function(resolve, reject) {
        findUserById(id, function(error, user) {
            if (error) {
                reject(error);
            } else {
                resolve(user);
            }
        });
    });
}

// Now we can use .then() chains instead of nesting
findUserByIdPromise(1)
    .then(function(user) {
        console.log('Found:', user.name); // "Found: Alice"
    })
    .catch(function(error) {
        console.error('Error:', error.message);
    });

Generic Promisify Utility

Instead of wrapping each function individually, you can create a generic utility that converts any error-first callback function into a Promise-returning function. This is the pattern used by Node.js built-in util.promisify.

// A generic promisify function
function promisify(callbackBasedFunction) {
    return function(...args) {
        return new Promise(function(resolve, reject) {
            callbackBasedFunction(...args, function(error, result) {
                if (error) {
                    reject(error);
                } else {
                    resolve(result);
                }
            });
        });
    };
}

// Convert callback functions to promise functions
const findUser = promisify(findUserById);
const getProfile = promisify(getUserProfile);
const getPermissions = promisify(getUserPermissions);
const getNotifs = promisify(getNotifications);
const logAct = promisify(logActivity);

// Now the entire flow is flat and readable
findUser(1)
    .then(function(auth) {
        return getProfile(auth.userId);
    })
    .then(function(profile) {
        return getPermissions(profile.role);
    })
    .then(function(permissions) {
        console.log('Permissions:', permissions);
    })
    .catch(function(error) {
        // ONE catch handles ALL errors in the chain
        console.error('Something failed:', error.message);
    });

Node.js util.promisify

Node.js provides a built-in util.promisify function that converts error-first callback functions into Promise-returning functions. It handles edge cases that a simple custom implementation might miss.

// Node.js built-in promisification
const util = require('util');
const fs = require('fs');

// Convert fs.readFile from callback to promise version
const readFileAsync = util.promisify(fs.readFile);

// Using the promisified version
readFileAsync('./config.json', 'utf8')
    .then(function(content) {
        const config = JSON.parse(content);
        console.log('Config loaded:', config);
    })
    .catch(function(error) {
        console.error('Failed to read config:', error.message);
    });

// Even better with async/await
async function loadConfig() {
    try {
        const content = await readFileAsync('./config.json', 'utf8');
        return JSON.parse(content);
    } catch (error) {
        console.error('Config error:', error.message);
        return getDefaultConfig();
    }
}

// Node.js also provides promise versions of many built-in modules
// const fs = require('fs').promises;  // or
// const fs = require('fs/promises');  // Node 14+

The Complete Transformation: Callbacks to async/await

The ultimate solution to callback hell is async/await, which allows you to write asynchronous code that looks and behaves like synchronous code. Here is the complete authentication flow from the callback hell example, rewritten with Promises and then with async/await:

// Step 1: Promisify all callback functions
const authenticate = promisify(authenticateUser);
const getProfile = promisify(getUserProfile);
const getPerms = promisify(getUserPermissions);
const getNotifs = promisify(getNotifications);
const logAct = promisify(logActivity);

// Step 2: Promise chain version -- flat, readable, single error handler
function initWithPromises(username, password) {
    let authData, profileData;

    authenticate(username, password)
        .then(function(auth) {
            authData = auth;
            return getProfile(auth.userId);
        })
        .then(function(profile) {
            profileData = profile;
            return getPerms(profile.role);
        })
        .then(function(permissions) {
            return getNotifs(authData.userId).then(function(notifications) {
                return { permissions: permissions, notifications: notifications };
            });
        })
        .then(function(data) {
            return logAct(authData.userId, 'login').then(function(logResult) {
                return {
                    profile: profileData,
                    permissions: data.permissions,
                    notifications: data.notifications,
                    logResult: logResult
                };
            });
        })
        .then(function(result) {
            console.log('Welcome,', result.profile.name);
            console.log('Permissions:', result.permissions);
            console.log('Notifications:', result.notifications.length);
        })
        .catch(function(error) {
            console.error('Failed:', error.message);
        });
}

// Step 3: async/await version -- looks synchronous, easiest to read
async function initWithAsyncAwait(username, password) {
    try {
        const auth = await authenticate(username, password);
        const profile = await getProfile(auth.userId);
        const permissions = await getPerms(profile.role);
        const notifications = await getNotifs(auth.userId);
        const logResult = await logAct(auth.userId, 'login');

        console.log('Welcome,', profile.name);
        console.log('Permissions:', permissions);
        console.log('Notifications:', notifications.length);
        console.log('Activity logged at:', logResult.timestamp);
    } catch (error) {
        console.error('Failed:', error.message);
    }
}

// Compare:
// Callback version: ~30 lines, 5+ levels of nesting, 5 error checks
// Promise version: ~35 lines, flat, 1 error handler
// Async/await version: ~15 lines, reads top-to-bottom, 1 try/catch

Running Callback Operations in Parallel

One limitation of sequential callbacks is that independent operations run one after another, wasting time. If two operations do not depend on each other, they should run simultaneously. With callbacks, this requires manual coordination. With Promises, it is trivial using Promise.all.

// CALLBACK VERSION: Manual parallel execution
function loadDashboardData(userId, callback) {
    let profile = null;
    let notifications = null;
    let completedCount = 0;
    let hasError = false;

    function checkComplete() {
        completedCount++;
        if (hasError) return;
        if (completedCount === 2) {
            callback(null, { profile: profile, notifications: notifications });
        }
    }

    getUserProfile(userId, function(err, result) {
        if (err) {
            hasError = true;
            return callback(err, null);
        }
        profile = result;
        checkComplete();
    });

    getNotifications(userId, function(err, result) {
        if (err) {
            hasError = true;
            return callback(err, null);
        }
        notifications = result;
        checkComplete();
    });
}

// PROMISE VERSION: Clean and built-in
async function loadDashboardDataAsync(userId) {
    try {
        // Both requests start simultaneously
        const [profile, notifications] = await Promise.all([
            getProfile(userId),
            getNotifs(userId)
        ]);

        return { profile, notifications };
    } catch (error) {
        console.error('Dashboard load failed:', error.message);
        throw error;
    }
}

Choosing Between Callbacks, Promises, and async/await

Each pattern has its place in modern JavaScript development. Understanding when to use each one makes you a more effective developer.

• Use callbacks for -- Simple event handlers (addEventListener), synchronous array methods (map, filter, reduce), one-off timer functions (setTimeout), and situations where you are working with a library that only provides a callback API.
• Use Promises for -- Composing multiple asynchronous operations, running operations in parallel with Promise.all, racing between operations with Promise.race, and creating public APIs that other developers will consume.
• Use async/await for -- Sequential asynchronous operations where each step depends on the previous one, complex control flow with conditionals and loops involving async operations, and any situation where readability is important (which is almost always).
• Avoid -- Nesting more than two levels of callbacks. If you find yourself nesting three or more callbacks, refactor to Promises or async/await immediately.

// CALLBACKS -- Good for simple, one-off async operations
document.getElementById('btn').addEventListener('click', handleClick);
setTimeout(showReminder, 5000);
[1, 2, 3].map(function(n) { return n * 2; });

// PROMISES -- Good for composable async operations
function fetchData(url) {
    return fetch(url).then(function(response) { return response.json(); });
}

// Multiple parallel operations
Promise.all([fetchData('/users'), fetchData('/posts')])
    .then(function([users, posts]) {
        renderPage(users, posts);
    });

// ASYNC/AWAIT -- Good for sequential async with clear flow
async function processOrder(orderId) {
    const order = await getOrder(orderId);
    const inventory = await checkInventory(order.items);

    if (!inventory.available) {
        await notifyCustomer(order.customerId, 'Out of stock');
        return { success: false, reason: 'inventory' };
    }

    const payment = await processPayment(order.total);
    await updateInventory(order.items);
    await sendConfirmation(order.customerId, order);

    return { success: true, paymentId: payment.id };
}

Common Callback Anti-Patterns

Avoid these common mistakes when working with callbacks:

// ANTI-PATTERN 1: Not handling errors
// BAD -- ignores the error parameter
getData(id, function(err, data) {
    console.log(data.name); // Crashes if err exists and data is null
});

// GOOD -- always check errors first
getData(id, function(err, data) {
    if (err) {
        console.error('Failed:', err.message);
        return;
    }
    console.log(data.name);
});

// ANTI-PATTERN 2: Calling the callback multiple times
// BAD -- callback might be called twice
function riskyFunction(value, callback) {
    if (value < 0) {
        callback(new Error('Negative value'));
        // Forgot to return! Code continues executing
    }
    callback(null, value * 2);
}

// GOOD -- use return to prevent double calls
function safeFunction(value, callback) {
    if (value < 0) {
        return callback(new Error('Negative value'));
    }
    callback(null, value * 2);
}

// ANTI-PATTERN 3: Mixing sync and async callbacks
// BAD -- sometimes sync, sometimes async (Zalgo)
function inconsistentFunction(key, callback) {
    if (cache[key]) {
        callback(null, cache[key]); // Synchronous!
    } else {
        fetchFromServer(key, callback); // Asynchronous!
    }
}

// GOOD -- always async
function consistentFunction(key, callback) {
    if (cache[key]) {
        setTimeout(function() {
            callback(null, cache[key]);
        }, 0);
    } else {
        fetchFromServer(key, callback);
    }
}

// ANTI-PATTERN 4: Throwing inside an async callback
// BAD -- throw inside async callback is uncatchable
getData(id, function(err, data) {
    if (err) throw err; // This crashes the entire process!
    processData(data);
});

// GOOD -- pass errors to the callback or handle them
getData(id, function(err, data) {
    if (err) {
        console.error('Handled error:', err.message);
        return;
    }
    processData(data);
});

Summary: The Evolution of Asynchronous JavaScript

Understanding callbacks is essential even in modern JavaScript because they remain the foundation on which Promises and async/await are built. Here is the evolution path:

1. Callbacks (ES1+) -- The original pattern. Simple and universal, but leads to nesting and inversion of control problems at scale.
2. Promises (ES2015) -- Provide a standard interface for async results. Enable chaining, parallel execution, and centralized error handling. Eliminate callback hell for sequential operations.
3. async/await (ES2017) -- Syntactic sugar over Promises that makes async code look synchronous. The cleanest and most readable approach for most use cases.

Each layer builds on the previous one. Async/await uses Promises internally, and Promises ultimately resolve by executing callbacks. Knowing how callbacks work gives you a deeper understanding of the entire async model and helps you debug issues that occur at any level of the abstraction.