In this article, you’ll learn how overworked managers, busy waiters, and train stations can help bring home the fundamental concept of the event loop. If you’re working with Node, you’ll need to understand how the event loop works, as it lies at the root of some of the most powerful applications today.

Table of Contents

• Prerequisites

• What are Synchronous and Asynchronous Code?

• What Concurrency and Parallelism Mean

  • Concurrency in Node.js

  • Parallelism in Node.js

• What is the Event Loop?

• The Phases of the Event Loop

• Conclusion

Prerequisites

In order to seamlessly follow along with this article, it would help if you are familiar with the following concepts:

1. A basic understanding of JavaScript: Node.js runs on JavaScript, so you’ll need to understand variables, functions, and control flow.

2. Familiarity with Node.js basics: Running simple scripts with Node and requiring modules.

3. Some exposure to asynchronous patterns: Knowing what patterns such as setTimeout() do.

4. Some familiarity with basic CPU concepts (cores and threads): This will help you better understand concurrency and parallelism.

5. Awareness of promises and async/await: This is optional and not a strict requirement, but will be helpful.

What are Synchronous and Asynchronous Code?

When writing code for Node.js applications, there are two different ways it can run: synchronous (sync) and asynchronous (async). Synchronous code is referred to as blocking because when it runs, no other code runs until execution is complete.

An analogy for this is a busy restaurant. Picture a waiter who refuses to wait on other tables until the table they’re presently serving has received their orders and has started eating. While the food is being prepared, the waiter waits around doing nothing and only approaches your table to take your order when they are completely finished with the previous table. Needless to say, the waiter may not receive a great tip for that service.

This is what synchronous code is. It halts the execution of other processes until it’s complete. You can see how it works in the example below:

const syncWaiter = (name) => {
    console.log(`${name} attends to tables pretty slowly.`);
};

syncWaiter("Devin");
console.log("At least all the orders are correct!");

The code above will be run in sequence, in the order it appears.

Asynchronous code, unlike synchronous code, doesn’t halt all other processes until one task is executed – rather, it proceeds to carry out other tasks while a longer process runs in the background.

Using our waiter analogy, in this case the waiter in the restaurant would go take an order from one table, pass the order to the kitchen, and while it’s being prepared, proceeds to your table to take your order as well. This way, the waiter is able to ensure different processes are started even if one process takes a bit longer than the rest. Check out the example below:

const asyncWaiter = (name) => {
    setTimeout(()=> {console.log(`${name} attends to tables pretty quickly.`)}, 3000)
};

asyncWaiter("James");
console.log("Wow! All the tables are attended to in a short time.");

Unlike synchronous code, this code does run the function asyncWaiter() – but the callback inside the function executes later. When the duration elapses, the result is then shown on the screen. This is why asynchronous programs are referred to as non-blocking. They don’t halt the program, but move from one available task to another.

The code above returns the following:

Wow! All the tables are attended to in a short time.
James attends to tables pretty quickly.

This print order happens because of how the event loop manages tasks: the synchronous console.log() that comes after asyncWaiter() runs immediately, while the asynchronous callback inside asyncWaiter() (from setTimeout) is scheduled to run later. If you don’t understand this just yet, don’t worry as I’ll break it down in detail shortly.

What Concurrency and Parallelism Mean

Node.js is single-threaded but often gives the appearance of a multi-threaded environment due to how it handles concurrency and parallelism. A thread is a single sequence of instructions executed by the CPU independently. Think of it like a single waiter named James in a restaurant.

If James handles multiple tasks around the same time and quickly, an onlooker outside the restaurant who sees the number of customers moving in and out of the restaurant may assume that there are a ton of waiters serving tables. In reality, James just handles his tasks asynchronously.

Before grasping the concept of the event loop, it’s good to understand what concurrency and parallelism are, as they help explain this.

Concurrency in Node.js

Concurrency means having multiple processes run around the same time. In the waiter analogy, it is like James carrying out different tasks, though not simultaneously. He could, for instance take an order from a table and, while waiting for the food to arrive, request that extra salt be provided to another table. While the salt is on its way, he uses the waiting time to read the bill to a third table.

The key idea is that James never sits idle — he works on other tasks while waiting for one to finish. If this sounds an awful lot like asynchronous programming, it is because asynchronous code is just one way to achieve concurrency.

Other ways to execute concurrency are multithreading on a single CPU core and coroutines which are just functions that pause their execution to resume at a later time.

Parallelism in Node.js

Parallelism, on the other hand, also means having several tasks run at the same time – but instead of the tasks just being processed around the same time, they are executed at exactly the same time, simultaneously. In this case, the restaurant manager decides to hire multiple waiters and each table has a waiter who is taking orders at exactly the same time.

Parallelism can be achieved using multithreading on multiple CPU cores. In this setup, the threads share the same memory and run simultaneously while using clusters which run independently – each with its own memory space. Here’s a clear example of parallelism using the worker_threads module:

const { Worker}  = require('worker_threads');

new Worker('./worker.js');
new Worker('./worker.js');
new Worker('./worker.js');

console.log("Main thread keeps running in the process...");

The code above creates three worker threads in parallel on a multi-core machine. This doesn’t stop the main thread which continues to run, allowing each worker thread independently do its task. worker.js could be a simple file carrying out any task. In this case, it simply logs a message to the screen:

console.log("This worker thread is running here!");

Note that the argument for the Worker constructor can be any file path, and the order in which they are executed isn’t dependent on the order they appear in code. Each worker runs independently of the others and they run in parallel.

Concurrency and parallelism allow Node.js (which is single-threaded) to appear to manage multiple tasks simultaneously. Understanding these concepts sets the stage for the event loop, showing how Node.js manages to give the appearance of concurrency while still executing code in a single-threaded environment.

What is the Event Loop?

The event loop listens for events in the Node.js environment. It essentially listens for actions and then processes tasks or outputs values.

To better understand how this works, you can picture the Node.js environment as a fast-paced organization and the event loop as an overworked manager who refuses to hire a personal assistant. The manager oversees the operations of the entire office, and has a dedicated desk that contains whatever they are working on at that particular time. Let’s call this desk the call stack.

The call stack consists of whatever processes or tasks that Node.js is currently working on. When input is entered or code is written to do something, it gets moved to the call stack and from there gets executed.

The order in which this execution takes place is important, as synchronous code makes it to the call stack before asynchronous code. What happens to the asynchronous code you may ask? It goes into something known as the callback queue first before ending up on the call stack.

The callback queue is a lineup of asynchronous tasks that make it to the call stack only if the stack is empty. You can think of it like a file cabinet in the office, where asynchronous code that is processed by a specialized team of workers under the manager go to stay until the manager’s desk is cleared. The manager only heads to the cabinet when they’re done handling all the synchronous task on the call stack. This specialized team that handles asynchronous code like callbacks and async/await are the Node APIs or the Web APIs.

Node or Web APIs process asynchronous code. When the code comes in, it’s processed here and then placed in the callback queue for the event loop to pick up and take to the call stack. But there are some asynchronous tasks that are prioritized. These are known as microtasks, such as promises.

Microtasks are given particular priority and are queued in a special microtask queue. This is usually checked after an operation before checking the callback queue. If nothing is present, the event loop checks the callback queue but if some task exists such as process.nextTick(), it gets handled immediately. Macrotasks consist of tasks that are regularly scheduled and handled by the event loop only after the microtasks are treated, such as setTimeout() and setInterval().

So as you can see, the event loop is basically what it sounds like – a loop. It looks through events and handles tasks based on a prioritized schedule.

One thing to note, though, is that even within callback queues and microtask queues, there are phases. The event loop, for instance, must handle certain tasks before others even within the same category. This is where the phases of the event loop come in.

The Phases of the Event Loop

By analogy, the event loop is akin to a manager who checks the status of projects and tasks at regular intervals. In this case, they have a specific schedule for checking the status of projects. Some projects or tasks take priority over others, and the manager has to look through them in a set order.

You can also visualize event loop phases as a train moving from station to station. It starts from one location and moves to others in a particular order until it’s complete, then starts the journey again. This arrangement determines what tasks get executed before others.

Here are the phases of the event loop in order:

1. The timers phase: This phase executes the setTimeout() and setInterval() callbacks after the duration is run. The event loop starts here, like the first station on a train’s journey.

2. The pending callbacks phase: These are system-level callbacks, checked after the timers phase operations.

3. The poll phase: This phase handles input/output (I/O) events and executes the callbacks. In the absence of callbacks, the event loop waits for new ones here.

4. The check phase: This phase executes setImmediate() callbacks.

5. Close callbacks: This phase is concerned with executing close events like socket closes.

These callback events are checked in order and run accordingly, so that if setTimeout() and setImmediate() are in the same code, setTimeout() runs first unless the “train” is say, in the Poll Phase of the loop so that setImmediate() runs before setTimeout().

You can see this illustrated with the example below:

const fs = require('fs');

fs.readFile('trainMap.txt', () => {
    setTimeout(() => {
        console.log("Train takes off");
    }, 0);
    setImmediate(() => {
        console.log("Oops! Immediate halt! There's a cat on the tracks!");
    })
});

You see in the code above that the callbacks are handled asynchronously. Recall that the event loop waits for new callbacks in the poll phase. What this means is that since fs.readfile() is a callback, it gets processed in the poll phase.

setTimeout() is set to run in the timers phase but the event loop proceeds to the check phase (which comes next) where setImmediate() is executed. This is why setImmediate() runs before setTimeout() in this case. The event loop then continues from the check phase to the close phase, back to the timers phase, repeating this cycle continuously.

This explains why you see the output below printed to the screen:

Oops! Immediate halt! There's a cat on the tracks!
Train takes off

This illustrates how the event loop enforces order of execution across the different phases, ensuring that asynchronous operations run in the correct sequence.

Conclusion

The Node.js event loop can sometimes appear mysterious, but it really isn’t as complex as it first seems. At its core, it really is just the engine that ensures JavaScript can handle multiple tasks without freezing.

In this article, you’ve learnt about synchronous and asynchronous code, concurrency, parallelism, and how these concepts help explain the event loop and the phases of the event loop. Understanding how they work gives you the confidence to write asynchronous code without fear, debug more efficiently, and appreciate the power behind Node.js’s ability to handle concurrent tasks.

In this article, you will learn the differences between these two approaches, when to use each one, and how to make the right choice for your specific use case.

Here’s what we’ll cover:

1. What Are Asynchronous Operations?

2. What Are Promises?

3. What Is Async/Await?

4. Practical Examples: Promises vs Async/Await

5. When to Use Promises

6. When to Use Async/Await

7. Performance Considerations

8. Error Handling Patterns

9. Best Practices

10. Making the Right Choice

11. Conclusion

What Are Asynchronous Operations?

Before explaining what Promises and Async/Await mean, it is important to understand what asynchronous operations are.

Synchronous operations execute one after another, blocking the next operation until the current one completes. Here’s an example in JavaScript:

console.log("First");
console.log("Second");
console.log("Third");

// Output:
// First
// Second
// Third

Asynchronous operations, on the other hand, can start an operation and continue executing other code while waiting for the first operation to complete. Here’s an example in JavaScript:

console.log("First");

setTimeout(() => {
    console.log("Second (after 2 seconds)");
}, 2000);

console.log("Third");

// Output:
// First
// Third
// Second (after 2 seconds)

In this example, setTimeout() is an asynchronous function that schedules code to run after a specified delay without blocking the execution of subsequent code.

What Are Promises?

A Promise is a JavaScript object that represents the eventual completion (or failure) of an asynchronous operation. Think of it as a placeholder for a value that will be available in the future.

Promise States

A Promise can be in one of three states:

1. Pending: The initial state – the operation hasn't been completed yet

2. Fulfilled (Resolved): The operation completed successfully

3. Rejected: The operation failed

Basic Promise Syntax

Here's how you create and use a basic Promise:

// Creating a Promise
const myPromise = new Promise((resolve, reject) => {
    // Simulate an asynchronous operation
    setTimeout(() => {
        const success = true;

        if (success) {
            resolve("Operation completed successfully!");
        } else {
            reject("Operation failed!");
        }
    }, 2000);
});

// Using the Promise
myPromise
    .then((result) => {
        console.log(result); // "Operation completed successfully!"
    })
    .catch((error) => {
        console.log(error);
    });

Let's break down this code:

• new Promise() creates a new Promise object

• The Promise constructor takes a function with two parameters: resolve and reject

• resolve() is called when the operation succeeds

• reject() is called when the operation fails

• .then() handles the successful case

• .catch() handles the error case

Chaining Promises

Promise chaining is a powerful technique that allows you to link multiple asynchronous operations together in a sequence. When you want to perform multiple operations where each depends on the result of the previous one, promise chaining provides an elegant solution. You can chain multiple Promises together using .then():

function fetchUserData(userId) {
    return new Promise((resolve, reject) => {
        setTimeout(() => {
            resolve({ id: userId, name: "John Doe" });
        }, 1000);
    });
}

function fetchUserPosts(user) {
    return new Promise((resolve, reject) => {
        setTimeout(() => {
            resolve([
                { title: "Post 1", author: user.name },
                { title: "Post 2", author: user.name }
            ]);
        }, 1000);
    });
}

// Chaining Promises
fetchUserData(123)
    .then((user) => {
        console.log("User:", user);
        return fetchUserPosts(user);
    })
    .then((posts) => {
        console.log("Posts:", posts);
    })
    .catch((error) => {
        console.log("Error:", error);
    });

In this example:

• fetchUserData() returns a Promise that resolves with user information

• fetchUserPosts() returns a Promise that resolves with the user's posts

• We chain these operations using .then()

• Each .then() receives the resolved value from the previous Promise

Downsides of Promise Chaining:

While promise chaining is powerful, it does have some potential drawbacks:

1. "Callback Hell" in disguise: Complex chains can become difficult to read and debug, especially with nested logic

2. Complex error handling: Each step in the chain needs proper error handling, and errors can propagate in unexpected ways

3. Debugging challenges: Stack traces through promise chains can be harder to follow

4. Mixing synchronous and asynchronous logic: It can be tempting to put synchronous operations inside .then() blocks, which can lead to confusion

What Is Async/Await?

Async/Await is syntactic sugar built on top of Promises. It allows you to write asynchronous code that looks and behaves more like synchronous code, making it easier to read and understand.

Basic Async/Await Syntax

Here's the same Promise example rewritten using Async/Await:

// Creating an async function
async function performOperation() {
    try {
        const result = await myPromise;
        console.log(result); // "Operation completed successfully!"
    } catch (error) {
        console.log(error);
    }
}

performOperation();

Let's break down this code:

• The async keyword before a function declaration makes it an asynchronous function

• The await keyword pauses the function execution until the Promise resolves

• The try/catch blocks handle errors, similar to .catch() in Promises

Converting Promise Chains to Async/Await

Here's the previous chaining example using Async/Await:

async function getUserDataAndPosts(userId) {
    try {
        const user = await fetchUserData(userId);
        console.log("User:", user);

        const posts = await fetchUserPosts(user);
        console.log("Posts:", posts);

        return posts;
    } catch (error) {
        console.log("Error:", error);
        throw error; // Re-throw the error if needed
    }
}

getUserDataAndPosts(123);

This code is much more readable and follows a linear flow that's easier to understand.

Practical Examples: Promises vs Async/Await

Let's compare both approaches with real-world scenarios.

Example 1: Making API Calls

Using Promises:

function fetchDataWithPromises() {
    fetch('https://jsonplaceholder.typicode.com/users/1')
        .then(response => {
            if (!response.ok) {
                throw new Error('Network response was not ok');
            }
            return response.json();
        })
        .then(user => {
            console.log('User data:', user);
            return fetch(`https://jsonplaceholder.typicode.com/users/${user.id}/posts`);
        })
        .then(response => response.json())
        .then(posts => {
            console.log('User posts:', posts);
        })
        .catch(error => {
            console.error('Error:', error);
        });
}

Using Async/Await:

async function fetchDataWithAsyncAwait() {
    try {
        const userResponse = await fetch('https://jsonplaceholder.typicode.com/users/1');

        if (!userResponse.ok) {
            throw new Error('Network response was not ok');
        }

        const user = await userResponse.json();
        console.log('User data:', user);

        const postsResponse = await fetch(`https://jsonplaceholder.typicode.com/users/${user.id}/posts`);
        const posts = await postsResponse.json();
        console.log('User posts:', posts);

    } catch (error) {
        console.error('Error:', error);
    }
}

The Async/Await version is more readable and follows a natural top-to-bottom flow.

Example 2: Handling Multiple Asynchronous Operations

Using Promises:

function processMultipleOperations() {
    const promise1 = fetch('https://jsonplaceholder.typicode.com/users/1');
    const promise2 = fetch('https://jsonplaceholder.typicode.com/users/2');
    const promise3 = fetch('https://jsonplaceholder.typicode.com/users/3');

    Promise.all([promise1, promise2, promise3])
        .then(responses => {
            return Promise.all(responses.map(response => response.json()));
        })
        .then(users => {
            console.log('All users:', users);
        })
        .catch(error => {
            console.error('Error:', error);
        });
}

Using Async/Await:

async function processMultipleOperationsAsync() {
    try {
        const promise1 = fetch('https://jsonplaceholder.typicode.com/users/1');
        const promise2 = fetch('https://jsonplaceholder.typicode.com/users/2');
        const promise3 = fetch('https://jsonplaceholder.typicode.com/users/3');

        const responses = await Promise.all([promise1, promise2, promise3]);
        const users = await Promise.all(responses.map(response => response.json()));

        console.log('All users:', users);
    } catch (error) {
        console.error('Error:', error);
    }
}

Both approaches use Promise. all() to wait for multiple operations to complete simultaneously.

When to Use Promises

Promises are still useful in several scenarios:

1. Working with Existing Promise-Based APIs

Popular libraries like Axios, fetch(), and many Node.js modules return Promises.

How to identify promise-based APIs:

• The function returns an object with .then() and .catch() methods

• The documentation mentions "returns a Promise"

• The function doesn't require a callback parameter

Many libraries and APIs return Promises directly:

// Axios library returns Promises
axios.get('/api/users')
    .then(response => response.data)
    .then(users => console.log(users))
    .catch(error => console.error(error));

// fetch() API returns Promises
fetch('/api/data')
    .then(response => response.json())
    .then(data => console.log(data));

// Node.js fs.promises returns Promises
import { readFile } from 'fs/promises';
readFile('./config.json', 'utf8')
    .then(data => JSON.parse(data))
    .then(config => console.log(config));

2. Functional Programming Patterns

Promises are immutable objects that represent future values, making them perfect for functional programming approaches. They can be easily composed, chained, and transformed without side effects. The .then() method essentially maps over the future value, similar to how Array.map() works with collections.

Promises work well with functional programming approaches because they are composable and can be easily passed around as first-class objects:

// Functional composition with Promises
const processUsers = (userIds) => {
    return Promise.all(
        userIds.map(id => fetchUser(id))  // Transform each ID to a Promise
    )
    .then(users => users.filter(user => user.active))  // Filter active users
    .then(activeUsers => activeUsers.map(user => user.email));  // Extract emails
};

// Pipeline approach
const createUserPipeline = (userId) => {
    return fetchUser(userId)
        .then(validateUser)
        .then(enrichUserData)
        .then(formatUserResponse)
        .then(logUserActivity);
};

// Composing multiple Promise-returning functions
const compose = (...fns) => (value) => 
    fns.reduce((promise, fn) => promise.then(fn), Promise.resolve(value));

const userProcessor = compose(
    fetchUser,
    validateUser,
    enrichUserData,
    saveUser
);

3. Creating Reusable Promise Utilities

Reusable promise utilities are helper functions that abstract common asynchronous patterns into reusable components. They're particularly useful for cross-cutting concerns like retries, timeouts, rate limiting, and caching. These utilities can be used across different parts of your application without being tied to specific business logic.

When they're useful:

• When you need the same asynchronous pattern in multiple places

• For handling common failure scenarios (network timeouts, retries)

• When building middleware or interceptors

• For performance optimizations like batching or debouncing

// Timeout utility
function timeout(ms) {
    return new Promise(resolve => setTimeout(resolve, ms));
}

// Retry utility with exponential backoff
function retry(fn, retries = 3, delay = 1000) {
    return fn().catch(error => {
        if (retries > 0) {
            console.log(`Retrying... ${retries} attempts left`);
            return timeout(delay).then(() => retry(fn, retries - 1, delay * 2));
        }
        throw error;
    });
}

// Rate limiting utility
function rateLimit(fn, maxCalls, timeWindow) {
    let calls = [];

    return function(...args) {
        const now = Date.now();
        calls = calls.filter(time => now - time < timeWindow);

        if (calls.length >= maxCalls) {
            const waitTime = timeWindow - (now - calls[0]);
            return timeout(waitTime).then(() => fn.apply(this, args));
        }

        calls.push(now);
        return fn.apply(this, args);
    };
}

// Usage examples
const apiCall = () => fetch('/api/data').then(r => r.json());
const resilientApiCall = retry(apiCall, 3);
const rateLimitedApiCall = rateLimit(apiCall, 5, 60000); // 5 calls per minute

When to Use Async/Await

Async/Await is preferred in most modern JavaScript applications. It has various advantages over Promises, such as:

1. Improved readability: Code reads like synchronous code, making it easier to understand the flow

2. Better debugging: Stack traces are cleaner and easier to follow

3. Simplified error handling: Single try/catch block can handle multiple async operations

4. Reduced nesting: Eliminates the "pyramid of doom" that can occur with promise chains

5. Easier testing: Async functions are easier to test and mock

6. Better IDE support: Better autocomplete and type inference in modern editors

Let’s look at some examples that demonstrate when async/await would be a better choice.

1. Sequential Operations

When you need to perform operations one after another:

async function processUserData(userId) {
    try {
        const user = await fetchUser(userId);
        const preferences = await fetchUserPreferences(user.id);
        const recommendations = await generateRecommendations(user, preferences);

        return {
            user,
            preferences,
            recommendations
        };
    } catch (error) {
        console.error('Failed to process user data:', error);
        throw error;
    }
}

Why this is better than promises: With promise chaining, you'd need to nest .then() calls or return values through the chain, making it harder to track data flow.

2. Complex Error Handling

Async/await allows you to use familiar try/catch syntax and handle errors at the exact point where they might occur. You can have multiple try/catch blocks for different error scenarios, and the error handling logic is co-located with the code that might throw the error.

async function complexOperation(data) {
    try {
        // First level: preprocessing errors
        const processedData = await preprocessData(data);

        try {
            // Second level: critical operation errors
            const result = await performCriticalOperation(processedData);
            return result;
        } catch (criticalError) {
            // Handle critical operation errors specifically
            console.error('Critical operation failed:', criticalError);

            // We can make decisions based on the error type
            if (criticalError.code === 'TEMPORARY_FAILURE') {
                console.log('Attempting fallback operation...');
                const fallbackResult = await performFallbackOperation(processedData);
                return fallbackResult;
            } else {
                // Re-throw if it's not recoverable
                throw new Error(`Critical failure: ${criticalError.message}`);
            }
        }

    } catch (preprocessError) {
        // Handle preprocessing errors differently
        console.error('Preprocessing failed:', preprocessError);

        // We can inspect the error and decide how to handle it
        if (preprocessError.code === 'INVALID_DATA') {
            throw new Error('Invalid input data provided');
        } else {
            throw new Error('Unable to process data');
        }
    }
}

Explanation of the code:

• The outer try/catch handles preprocessing errors

• The inner try/catch specifically handles critical operation errors

• Each error handler can make different decisions based on error types

• The code clearly shows the error-handling strategy at each level

• You can easily add logging, metrics, or recovery logic at each level

3. Conditional Asynchronous Logic

Async/await makes it natural to use standard control flow (if/else, loops, switch statements) with asynchronous operations. This is much cleaner than trying to implement conditional logic within promise chains.

async function smartUserProcess(userId) {
    try {
        // First, get the user data
        const user = await fetchUser(userId);
        console.log(`Processing user: ${user.name} (Premium: ${user.isPremium})`);

        // Make decisions based on the async result
        if (user.isPremium) {
            console.log('User is premium - fetching premium features');

            // Premium users get additional data
            const premiumData = await fetchPremiumFeatures(user.id);

            // We can make further decisions based on premium data
            if (premiumData.analyticsEnabled) {
                console.log('Analytics enabled - generating premium analytics');
                const analytics = await generatePremiumAnalytics(user, premiumData);
                return { user, premiumData, analytics };
            } else {
                return { user, premiumData };
            }

        } else {
            console.log('User is basic - fetching basic features');

            // Basic users get different treatment
            const basicData = await fetchBasicFeatures(user.id);

            // Check if user qualifies for upgrade prompts
            if (basicData.usageLevel > 0.8) {
                console.log('User has high usage - checking upgrade eligibility');
                const upgradeOffer = await checkUpgradeEligibility(user);
                return { user, basicData, upgradeOffer };
            } else {
                return { user, basicData };
            }
        }
    } catch (error) {
        console.error('User processing failed:', error);

        // Even error handling can be conditional
        if (error.code === 'USER_NOT_FOUND') {
            throw new Error('User does not exist');
        } else if (error.code === 'NETWORK_ERROR') {
            throw new Error('Network connectivity issue');
        } else {
            throw error;
        }
    }
}

Explanation of the code:

• We await the user fetch and immediately use the result in an if statement

• Each branch of the conditional can perform different async operations

• We can nest conditions naturally (like checking analyticsEnabled)

• Standard control flow works seamlessly with async operations

• Error handling can also be conditional based on error types

• The code reads like synchronous code but handles async operations correctly

Performance Considerations

Understanding the performance implications of different asynchronous patterns is crucial for building efficient JavaScript applications. The main performance consideration is whether your asynchronous operations can run in parallel or must be executed sequentially.

When working with multiple asynchronous operations, you have two main execution patterns: sequential (one after another) and parallel (multiple operations at the same time). The choice between these patterns can significantly impact your application's performance and user experience.

Sequential vs Parallel Execution

Sequential Execution (slower but sometimes necessary):

Sequential execution means waiting for each operation to complete before starting the next one. This is slower but necessary when operations depend on each other.

// This takes ~3 seconds total (1 + 1 + 1)
async function sequentialOperations() {
    console.time('Sequential Operations');

    const result1 = await operation1(); // 1 second - must complete first
    console.log('Operation 1 completed:', result1);

    const result2 = await operation2(); // 1 second - starts after operation1
    console.log('Operation 2 completed:', result2);

    const result3 = await operation3(); // 1 second - starts after operation2
    console.log('Operation 3 completed:', result3);

    console.timeEnd('Sequential Operations');
    return [result1, result2, result3];
}

Use sequential execution when:

• Each operation depends on the result of the previous one

• You need to process results in a specific order

• Operations must be rate-limited (for example, API calls with rate limits)

• You want to avoid overwhelming external services

Parallel Execution (faster when possible):

Parallel execution means starting all operations at the same time and waiting for all of them to complete. This is much faster when operations are independent.

// This takes ~1 second total (all operations run simultaneously)
async function parallelOperations() {
    console.time('Parallel Operations');

    // Start all operations immediately - they run concurrently
    const promise1 = operation1(); // starts immediately
    const promise2 = operation2(); // starts immediately  
    const promise3 = operation3(); // starts immediately

    console.log('All operations started, waiting for completion...');

    // Wait for all operations to complete
    const [result1, result2, result3] = await Promise.all([
        promise1,
        promise2,
        promise3
    ]);

    console.log('All operations completed');
    console.timeEnd('Parallel Operations');
    return [result1, result2, result3];
}

Use parallel execution when:

• Operations are independent of each other

• You want to minimize total execution time

• Dealing with I/O operations (file reads, API calls, database queries)

• The order of completion doesn't matter

Advanced Example - Mixed Approach:

Sometimes you need a combination of both approaches:

javascriptasync function mixedApproach(userIds) {
    console.time('Mixed Approach');

    // Step 1: Fetch all users in parallel (they're independent)
    console.log('Fetching users in parallel...');
    const users = await Promise.all(
        userIds.map(id => fetchUser(id))
    );

    // Step 2: Process each user sequentially (to avoid overwhelming the recommendation service)
    console.log('Processing users sequentially...');
    const results = [];
    for (const user of users) {
        const preferences = await fetchUserPreferences(user.id);
        const recommendations = await generateRecommendations(user, preferences);
        results.push({ user, preferences, recommendations });

        // Small delay to be respectful to the API
        await new Promise(resolve => setTimeout(resolve, 100));
    }

    console.timeEnd('Mixed Approach');
    return results;
}

Use Promise.all() when operations can run independently and simultaneously.

Error Handling Patterns

Proper error handling is crucial for building robust applications. Different asynchronous patterns offer different approaches to error handling, each with their own advantages and use cases.

Error handling in asynchronous JavaScript can be challenging because errors can occur at different points in the execution flow. Understanding how to properly catch, handle, and recover from errors in both Promise and async/await patterns is essential for building reliable applications.

Promise Error Handling:

With Promises, errors are handled using the .catch() method. This approach provides fine-grained control over error handling at different points in the chain.

function promiseErrorHandling() {
    return fetchData()
        .then(data => {
            console.log('Data fetched successfully');
            return processData(data);
        })
        .then(result => {
            console.log('Data processed successfully');
            return saveResult(result);
        })
        .then(savedResult => {
            console.log('Result saved successfully');
            return savedResult;
        })
        .catch(error => {
            console.error('Error occurred in the chain:', error);

            // Handle different types of errors
            if (error.name === 'NetworkError') {
                console.log('Network issue detected, attempting retry...');
                return retryOperation();
            } else if (error.name === 'ValidationError') {
                console.log('Data validation failed:', error.message);
                return handleValidationError(error);
            } else if (error.name === 'StorageError') {
                console.log('Storage operation failed, using fallback');
                return saveToFallbackStorage(error.data);
            } else {
                console.log('Unknown error type:', error);
                throw error; // Re-throw if we can't handle it
            }
        });
}

Here’s what’s going on in this code:

• The .catch() method catches any error that occurs in the entire chain

• You can inspect the error object to determine the appropriate response

• Returning a value from .catch() recovers from the error

• Throwing an error or not returning anything propagates the error further

• The error handler has access to the original error context

Async/Await Error Handling

With async/await, errors are handled using try/catch blocks, which provide more familiar and flexible error-handling patterns.

async function asyncAwaitErrorHandling() {
    try {
        console.log('Starting data processing...');

        const data = await fetchData();
        console.log('Data fetched successfully');

        const result = await processData(data);
        console.log('Data processed successfully');

        const savedResult = await saveResult(result);
        console.log('Result saved successfully');

        return savedResult;

    } catch (error) {
        console.error('Error occurred during processing:', error);

        // Handle different types of errors with more complex logic
        if (error.name === 'NetworkError') {
            console.log('Network issue detected');

            // We can use async operations in error handling
            const retryCount = await getRetryCount();
            if (retryCount < 3) {
                console.log(`Retrying... (attempt ${retryCount + 1})`);
                await incrementRetryCount();
                return await retryOperation();
            } else {
                console.log('Max retries reached, switching to offline mode');
                return await switchToOfflineMode();
            }

        } else if (error.name === 'ValidationError') {
            console.log('Data validation failed:', error.message);

            // Handle validation errors with user feedback
            await logValidationError(error);
            return handleValidationError(error);

        } else if (error.name === 'StorageError') {
            console.log('Storage operation failed');

            // Try multiple fallback options
            try {
                return await saveToFallbackStorage(error.data);
            } catch (fallbackError) {
                console.log('Fallback storage also failed, using cache');
                return await saveToCache(error.data);
            }

        } else {
            console.log('Unknown error type, logging for analysis');
            await logErrorForAnalysis(error);
            throw error; // Re-throw unknown errors
        }
    }
}

Here’s what’s going on in the code:

• The try/catch block handles all errors in the async function

• You can use await inside catch blocks for error recovery operations

• Multiple nested try/catch blocks can handle different scenarios

• Error handling code can be as complex as needed, including loops and conditions

• The error handling logic is co-located with the code that might throw

Advanced Error Pattern – Specific Error Handling:

javascriptasync function advancedErrorHandling(userId) {
    try {
        const user = await fetchUser(userId);

        try {
            const sensitiveData = await fetchSensitiveData(user.id);
            return { user, sensitiveData };
        } catch (sensitiveError) {
            // Handle sensitive data errors specifically
            if (sensitiveError.code === 'PERMISSION_DENIED') {
                console.log('User lacks permission for sensitive data');
                return { user, sensitiveData: null, reason: 'permission_denied' };
            } else {
                // For other sensitive data errors, we still want to return the user
                console.warn('Sensitive data unavailable:', sensitiveError.message);
                return { user, sensitiveData: null, reason: 'data_unavailable' };
            }
        }

    } catch (userError) {
        // Handle user fetching errors
        if (userError.code === 'USER_NOT_FOUND') {
            throw new Error(`User ${userId} does not exist`);
        } else if (userError.code === 'NETWORK_ERROR') {
            throw new Error('Unable to connect to user service');
        } else {
            throw new Error(`Failed to fetch user: ${userError.message}`);
        }
    }
}

Best Practices

Following these best practices will help you write more reliable, maintainable, and performant asynchronous JavaScript code.

Always Handle Errors

One of the most common mistakes in asynchronous JavaScript is forgetting to handle errors. When an async operation fails without proper error handling, it can lead to unhandled promise rejections, application crashes, or silent failures that are difficult to debug.

Don't do this:

javascript// Missing error handling - this is dangerous!
async function badExample() {
    const data = await fetchData(); // What if this fails?
    const processed = await processData(data); // What if this fails?
    return await saveData(processed); // What if this fails?
}

// Usage - user has no idea if something went wrong
const result = await badExample();
console.log(result); // Could be undefined or cause a crash

Why this is problematic:

• If fetchData() fails, the entire function crashes

• The caller has no way to know what went wrong

• In production, this could lead to a poor user experience

• Debugging becomes much harder without proper error context

Do this instead:

javascript// Proper error handling with context and recovery
async function goodExample() {
    try {
        console.log('Starting data processing...');

        const data = await fetchData();
        console.log('Data fetched successfully');

        const processed = await processData(data);
        console.log('Data processed successfully');

        const result = await saveData(processed);
        console.log('Data saved successfully');

        return result;
    } catch (error) {
        // Log the error with context
        console.error('Data processing failed:', {
            error: error.message,
            step: error.step || 'unknown',
            timestamp: new Date().toISOString()
        });

        // Re-throw with more context or handle appropriately
        throw new Error(`Data processing failed: ${error.message}`);
    }
}

// Usage - caller knows how to handle failures
try {
    const result = await goodExample();
    console.log('Success:', result);
} catch (error) {
    console.error('Failed to process data:', error.message);
    // Handle the error appropriately for your application
    showErrorToUser('Data processing failed. Please try again.');
}

Why this is better:

• Every async operation is wrapped in try/catch

• Errors are logged with useful context

• The caller receives meaningful error messages

• The application can gracefully handle failures

Use Promise.all() for Independent Operations

A common performance anti-pattern is making independent async operations run sequentially when they could run in parallel. This unnecessarily increases the total execution time.

Don't do this:

javascript// Sequential when it could be parallel - this is inefficient!
async function inefficient() {
    console.time('Inefficient Approach');

    // These operations are independent but run one after another
    const user = await fetchUser();        // 500ms
    const posts = await fetchPosts();      // 300ms  
    const comments = await fetchComments(); // 400ms
    // Total time: ~1200ms

    console.timeEnd('Inefficient Approach');
    return { user, posts, comments };
}

Why this is problematic:

• Each operation waits for the previous one to complete

• Total execution time is the sum of all individual times

• Network resources are underutilized

• Users experience unnecessary delays

This is particularly common when fetching data for a dashboard or page that needs multiple pieces of information. Developers often write the code sequentially without considering that these operations can run simultaneously.

Do this instead:

javascript// Parallel execution - much more efficient!
async function efficient() {
    console.time('Efficient Approach');

    // Start all operations simultaneously
    const userPromise = fetchUser();        // starts immediately
    const postsPromise = fetchPosts();      // starts immediately
    const commentsPromise = fetchComments(); // starts immediately

    // Wait for all to complete
    const [user, posts, comments] = await Promise.all([
        userPromise,
        postsPromise, 
        commentsPromise
    ]);
    // Total time: ~500ms (longest individual operation)

    console.timeEnd('Efficient Approach');
    return { user, posts, comments };
}

Advanced example with error handling:

javascriptasync function efficientWithErrorHandling() {
    try {
        console.log('Starting parallel data fetch...');

        // Start all operations and handle individual failures
        const results = await Promise.allSettled([
            fetchUser().catch(error => ({ error: error.message, type: 'user' })),
            fetchPosts().catch(error => ({ error: error.message, type: 'posts' })),
            fetchComments().catch(error => ({ error: error.message, type: 'comments' }))
        ]);

        // Process results and handle partial failures
        const [userResult, postsResult, commentsResult] = results;

        return {
            user: userResult.status === 'fulfilled' ? userResult.value : null,
            posts: postsResult.status === 'fulfilled' ? postsResult.value : [],
            comments: commentsResult.status === 'fulfilled' ? commentsResult.value : [],
            errors: results
                .filter(result => result.status === 'rejected' || result.value?.error)
                .map(result => result.reason || result.value?.error)
        };

    } catch (error) {
        console.error('Failed to fetch data:', error);
        throw error;
    }
}

Why this is better:

• Operations run in parallel, reducing total execution time

• Network and CPU resources are used more efficiently

• The application feels more responsive to users

• Can handle partial failures gracefully

Don't Mix Patterns Unnecessarily

Mixing Promise chains with async/await in the same function creates inconsistent code that's harder to read, debug, and maintain. It can also lead to subtle bugs and makes the code flow less predictable.

Avoid this:

javascript// Mixing async/await with .then() - this is confusing!
async function mixedPattern() {
    const data = await fetchData();

    // Suddenly switching to Promise chain style
    return processData(data).then(result => {
        console.log('Processing complete');
        return saveResult(result);
    }).then(savedResult => {
        return savedResult.id;
    }).catch(error => {
        console.error('Error in promise chain:', error);
        throw error;
    });
}

Why this is problematic:

• Inconsistent error handling patterns (try/catch vs .catch())

• Harder to follow the execution flow

• Different debugging experiences

• More opportunities for bugs

• Team members need to understand multiple patterns

This often happens when developers are working with existing Promise-based code and try to gradually introduce async/await without fully converting the function.

Do this instead:

javascript// Consistent async/await - much clearer!
async function consistentPattern() {
    try {
        const data = await fetchData();
        console.log('Data fetched');

        const result = await processData(data);
        console.log('Processing complete');

        const savedResult = await saveResult(result);
        console.log('Result saved');

        return savedResult.id;
    } catch (error) {
        console.error('Error in async function:', error);
        throw error;
    }
}

Alternative consistent Promise approach:

javascript// If you prefer Promises, be consistent with that too
function consistentPromisePattern() {
    return fetchData()
        .then(data => {
            console.log('Data fetched');
            return processData(data);
        })
        .then(result => {
            console.log('Processing complete');
            return saveResult(result);
        })
        .then(savedResult => {
            console.log('Result saved');
            return savedResult.id;
        })
        .catch(error => {
            console.error('Error in promise chain:', error);
            throw error;
        });
}

Use Descriptive Variable Names in Async Functions

javascript// Poor naming
async function process(id) {
    const d = await fetch(id);
    const r = await transform(d);
    return r;
}

// Better naming
async function processUserProfile(userId) {
    const userData = await fetchUserData(userId);
    const transformedProfile = await transformUserData(userData);
    return transformedProfile;
}

Handle Timeouts for Long-Running Operations

javascript// Add timeout wrapper for reliability
function withTimeout(promise, timeoutMs) {
    const timeout = new Promise((_, reject) => {
        setTimeout(() => reject(new Error('Operation timed out')), timeoutMs);
    });

    return Promise.race([promise, timeout]);
}

// Usage
async function reliableDataFetch(userId) {
    try {
        // Timeout after 5 seconds
        const userData = await withTimeout(fetchUserData(userId), 5000);
        return userData;
    } catch (error) {
        if (error.message === 'Operation timed out') {
            console.log('Request timed out, using cached data');
            return getCachedUserData(userId);
        }
        throw error;
    }
}

Making the Right Choice

Here's a decision framework to help you choose:

Choose Promises When:

• Working with libraries that return Promises

• Writing functional programming style code

• Creating utility functions that other code will chain

• You need fine-grained control over Promise behavior

• Working with existing Promise-based codebases

Choose Async/Await When:

• Writing new application code

• You need sequential operations with a clear flow

• Complex error handling is required

• Working with conditional asynchronous logic

• Code readability is a priority

• You're building modern JavaScript applications

Consider Both When:

• Using Promise.all(), Promise.race(), or Promise.allSettled()

• Building complex asynchronous flows

• You need both the power of Promises and the readability of Async/Await

Conclusion

Both Promises and Async/Await are powerful tools for handling asynchronous operations in JavaScript. Promises provide flexibility and fine-grained control, while Async/Await offers cleaner, more readable code that's easier to debug and maintain.

In modern JavaScript development, Async/Await is generally preferred for application code due to its readability and ease of use. However, understanding Promises is still crucial since Async/Await is built on top of them, and many libraries and APIs still use Promises directly.

The key is to understand both approaches and choose the one that best fits your specific use case, team preferences, and project requirements. Remember that you can always mix both approaches when it makes sense – use Async/Await for your main application logic and Promises for utility functions and library integrations.

By mastering both techniques very well, you will be well-equipped to handle any asynchronous programming challenge in JavaScript.

Async programming is essential for creating responsive and efficient applications in JavaScript. TypeScript, a superset of JavaScript, makes it even easier to work with async programming.

There are several approaches to async programming in TypeScript, including using promises, async/await, and callbacks. We will cover each of these approaches in detail so that you can choose the best one(s) for your use case.

Table of Contents

1. Why is Async Programming Important?

2. How TypeScript Makes Async Programming Easier

3. How to Use Promises in TypeScript

   • How to Create a Promise

   • How to Chain Promises

4. How to Use Async / Await in TypeScript

5. How to Use Callbacks in TypeScript

6. Conclusion

Why is Async Programming Important?

Async programming is crucial for building responsive and efficient web applications. It allows tasks to run in the background while the rest of the program continues, keeping the user interface responsive to input. Also, async programming can boost overall performance by letting multiple tasks run at the same time.

There are many real-world examples of async programming, such as accessing user cameras and microphones and handling user input events. Even if you don't frequently create asynchronous functions, it's important to know how to use them correctly to make sure your application is reliable and performs well.

How TypeScript Makes Async Programming Easier

TypeScript offers several features that simplify async programming, including type safety, type inference, type checking, and type annotations.

With type safety, you can ensure your code behaves as expected, even when dealing with asynchronous functions. For instance, TypeScript can catch errors related to null and undefined values at compile time, saving you time and effort in debugging.

TypeScript's type inference and checking also reduce the amount of boilerplate code you need to write, making your code more concise and easier to read.

And TypeScript's type annotations provide clarity and documentation for your code, which is especially helpful when working with asynchronous functions that can be complex to understand.

Now let’s dive in and learn about these three key features of asynchronous programming: promises, async/await, and callbacks.

How to Use Promises in TypeScript

Promises are a powerful tool for handling asynchronous operations in TypeScript. For instance, you might use a promise to fetch data from an external API or to perform a time-consuming task in the background while your main thread keeps running.

To use a Promise, you create a new instance of the Promise class and pass it a function that carries out the asynchronous operation. This function should call the resolve method with the result when the operation succeeds or the reject method with an error if it fails.

Once the Promise is created, you can attach callbacks to it using the then method. These callbacks will be triggered when the Promise is fulfilled, with the resolved value passed as a parameter. If the Promise is rejected, you can attach an error handler using the catch method, which will be called with the reason for the rejection.

Using Promises offers several advantages over traditional callback-based methods. For example, Promises can help prevent "callback hell," a common issue in asynchronous code where nested callbacks become hard to read and maintain.

Promises also make error handling in asynchronous code easier, as you can use the catch method to manage errors that occur anywhere in the Promise chain.

Finally, Promises can simplify your code by providing a consistent, composable way to handle asynchronous operations, regardless of their underlying implementation.

How to Create a Promise

Promise syntax:

const myPromise = new Promise((resolve, reject) => {
  // Do some asynchronous operation
  // If the operation is successful, call resolve with the result
  // If the operation fails, call reject with an error object
});

myPromise
  .then((result) => {
    // Handle the successful result
  })
  .catch((error) => {
    // Handle the error
  });

// Example 1 on how to create a promise

function myAsyncFunction(): Promise<string> {
  return new Promise<string>((resolve, reject) => {
    // Some asynchronous operation
    setTimeout(() => {
      // Successful operation resolves promiseCheck out my latest blog post on mastering async programming in TypeScript! Learn how to work with Promises, Async/Await, and Callbacks to write efficient and scalable code. Get ready to take your TypeScript skills to the next level!
      const success = true;

      if (success) {
        // Resolve the promise with the operation result if the operation was successful
        resolve(
          `The result is success and your operation result is ${operationResult}`
        );
      } else {
        const rejectCode: number = 404;
        const rejectMessage: string = `The result is failed and your operation result is ${rejectCode}`;
        // Reject the promise with the operation result if the operation failed
        reject(new Error(rejectMessage));
      }
    }, 2000);
  });
}

// Use the promise
myAsyncFunction()
  .then((result) => {
    console.log(result); // output : The result is success and your operation result is 4
  })
  .catch((error) => {
    console.error(error); // output : The result is failed and your operation result is 404
  });

In the example above, we have a function called myAsyncFunction() that returns a promise. We use the Promise constructor to create the promise, which takes a callback function with resolve and reject arguments. If the asynchronous operation is successful, we call the resolve function. If it fails, we call the reject function.

The promise object returned by the constructor has a then() method, which takes success and failure callback functions. If the promise resolves successfully, the success callback function is called with the result. If the promise is rejected, the failure callback function is called with an error message.

The promise object also has a catch() method used to handle errors that occur during the promise chain. The catch() method takes a callback function, which is called if any error occurs in the promise chain.

Now, let's move on to how to chain promises in TypeScript.

How to Chain Promises

Chaining promises allows you to perform multiple asynchronous operations in sequence or in parallel. This is helpful when you need to carry out several async tasks one after another or at the same time. For instance, you might need to fetch data asynchronously and then process it asynchronously.

Let's look at an example of how to chain promises:

// Example on how chaining promises works
// First promise
const promise1 = new Promise((resolve, reject) => {
  const functionOne: string = "This is the first promise function";
  setTimeout(() => {
    resolve(functionOne);
  }, 1000);
});

// Second promise
const promise2 = (data: number) => {
  const functionTwo: string = "This is the second second promise  function";
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      resolve(` ${data}  '+'  ${functionTwo} `);
    }, 1000);
  });
};

// Chaining first and second promises together
promise1
  .then(promise2)
  .then((result) => {
    console.log(result); // output: This is the first promise function + This is the second second promise function
  })
  .catch((error) => {
    console.error(error);
  });

In the example above, we have two promises: promise1 and promise2. promise1 resolves after 1 second with the string "This is the first promise function." promise2 takes a number as input and returns a promise that resolves after 1 second with a string that combines the input number and the string "This is the second promise function."

We chain the two promises together using the then method. The output promise1 is passed as input to promise2. Finally, we use the then method again to log the output of promise2 to the console. If either promise1 or promise2 rejects, the error will be caught by the catch method.

Congratulations! You have learned how to create and chain promises in TypeScript. You can now use promises to perform asynchronous operations in TypeScript. Now, let's explore how Async/Await works in TypeScript.

How to Use Async / Await in TypeScript

Async/await is a syntax introduced in ES2017 to make working with Promises easier. It allows you to write asynchronous code that looks and feels like synchronous code.

In TypeScript, you can define an asynchronous function using the async keyword. This tells the compiler that the function is asynchronous and will return a Promise.

Now, let's see how to use async/await in TypeScript.

Async / Await Syntax:

// Async / Await Syntax in TypeScript
async function functionName(): Promise<ReturnType> {
  try {
    const result = await promise;
    // code to execute after promise resolves
    return result;
  } catch (error) {
    // code to execute if promise rejects
    throw error;
  }
}

In the example above, functionName is an async function that returns a Promise of ReturnType. The await the keyword is used to wait for the promise to resolve before moving to the next line of code.

The try/catch block is used to handle any errors that occur while running the code inside the async function. If an error happens, it will be caught by the catch block, where you can handle it appropriately.

Using Arrow Functions with Async / Await

You can also use arrow functions with async/await syntax in TypeScript:

const functionName = async (): Promise<ReturnType> => {
  try {
    const result = await promise;
    // code to execute after promise resolves
    return result;
  } catch (error) {
    // code to execute if promise rejects
    throw error;
  }
};

In the example above, functionName is defined as an arrow function that returns a Promise of ReturnType. The async keyword indicates that this is an asynchronous function, and the await keyword is used to wait for the promise to resolve before moving to the next line of code.

Async / Await with an API Call

Now, let's go beyond the syntax and fetch some data from an API using async/await.

interface User {
  id: number;
  name: string;
  email: string;
}

const fetchApi = async (): Promise<void> => {
  try {
    const response = await fetch("https://jsonplaceholder.typicode.com/users");

    if (!response.ok) {
      throw new Error(
        `Failed to fetch users (HTTP status code: ${response.status})`
      );
    }

    const data: User[] = await response.json();
    console.log(data);
  } catch (error) {
    console.error(error);
    throw error;
  }
};

fetchApi();

Here, we’re fetching data from the JSONPlaceholder API, converting it to JSON, and then logging it to the console. This is a real-world example of how to use async/await in TypeScript.

You should see user information in the console. This image shows the output:

Async/Await with Axios API call

// Example 2 on how to use async / await in typescript

const fetchApi = async (): Promise<void> => {
  try {
    const response = await axios.get(
      "https://jsonplaceholder.typicode.com/users"
    );
    const data = await response.data;
    console.log(data);
  } catch (error) {
    console.error(error);
  }
};

fetchApi();

In the example above, we define the fetchApi() function using async/await and the Axios.get() method to make an HTTP GET request to the specified URL. We use await to wait for the response, then extract the data using the data property of the response object. Finally, we log the data to the console with console.log(). Any errors that occur are caught and logged to the console with console.error().

We can achieve this using Axios, so you should see the same result in the console.

This image shows the output when using Axios in the console:

Note: Before you try the code above, you need to install Axios using npm or yarn.

npm install axios

yarn add axios

If you're not familiar with Axios, you can learn more about it here.

You can see that we used a try and catch block to handle errors. The try and catch block is a method for managing errors in TypeScript. So, whenever you make API calls like we just did, make sure you use a try and catch block to handle any errors.

Now, let's explore a more advanced use of the try and catch block in TypeScript:

// Example 3 on how to use async / await in typescript

interface Recipe {
  id: number;
  name: string;
  ingredients: string[];
  instructions: string[];
  prepTimeMinutes: number;
  cookTimeMinutes: number;
  servings: number;
  difficulty: string;
  cuisine: string;
  caloriesPerServing: number;
  tags: string[];
  userId: number;
  image: string;
  rating: number;
  reviewCount: number;
  mealType: string[];
}

const fetchRecipes = async (): Promise<Recipe[] | string> => {
  const api = "https://dummyjson.com/recipes";
  try {
    const response = await fetch(api);

    if (!response.ok) {
      throw new Error(`Failed to fetch recipes: ${response.statusText}`);
    }

    const { recipes } = await response.json();
    return recipes; // Return the recipes array
  } catch (error) {
    console.error("Error fetching recipes:", error);
    if (error instanceof Error) {
      return error.message;
    }
    return "An unknown error occurred.";
  }
};

// Fetch and log recipes
fetchRecipes().then((data) => {
  if (Array.isArray(data)) {
    console.log("Recipes fetched successfully:", data);
  } else {
    console.error("Error message:", data);
  }
});

In the example above, we define an interface Recipe that outlines the structure of the data we expect from the API. We then create the fetchRecipes() function using async/await and the fetch() method to make an HTTP GET request to the specified API endpoint.

We use a try/catch block to handle any errors that might occur during the API request. If the request is successful, we extract the data property from the response using await and return it. If an error occurs, we check for an error message and return it as a string if it exists.

Finally, we call the fetchRecipes() function and use .then() to log the returned data to the console. This example demonstrates how to use async/await with try/catch blocks to handle errors in a more advanced scenario, where we need to extract data from a response object and return a custom error message.

This image shows the output result of the code:

Async / Await with Promise.all

Promise.all() is a method that takes an array of promises as input (an iterable) and returns a single Promise as output. This Promise resolves when all the input promises have been resolved or if the input iterable contains no promises. It rejects immediately if any of the input promises are rejected or if non-promises throw an error, and it will reject with the first rejection message or error.

// Example of using async / await with Promise.all
interface User {
  id: number;
  name: string;
  email: string;
  profilePicture: string;
}

interface Post {
  id: number;
  title: string;
  body: string;
}

interface Comment {
  id: number;
  postId: number;
  name: string;
  email: string;
  body: string;
}

const fetchApi = async <T>(url: string): Promise<T> => {
  try {
    const response = await fetch(url);
    if (response.ok) {
      const data = await response.json();
      return data;
    } else {
      throw new Error(`Network response was not ok for ${url}`);
    }
  } catch (error) {
    console.error(error);
    throw new Error(`Error fetching data from ${url}`);
  }
};

const fetchAllApis = async (): Promise<[User[], Post[], Comment[]]> => {
  try {
    const [users, posts, comments] = await Promise.all([
      fetchApi<User[]>("https://jsonplaceholder.typicode.com/users"),
      fetchApi<Post[]>("https://jsonplaceholder.typicode.com/posts"),
      fetchApi<Comment[]>("https://jsonplaceholder.typicode.com/comments"),
    ]);
    return [users, posts, comments];
  } catch (error) {
    console.error(error);
    throw new Error("Error fetching data from one or more APIs");
  }
};

fetchAllApis()
  .then(([users, posts, comments]) => {
    console.log("Users: ", users);
    console.log("Posts: ", posts);
    console.log("Comments: ", comments);
  })
  .catch((error) => console.error(error));

In the code above, we used Promise.all to fetch multiple APIs at the same time. If you have several APIs to fetch, you can use Promise.all to get them all at once. As you can see, we used map to loop through the array of APIs and then pass it to Promise.all to fetch them simultaneously.

The image below shows the output from the API calls:

Let's see how to use Promise.all with Axios:

// Example of using async / await with axios and Promise.all

const fetchApi = async () => {
  try {
    const urls = [
      "https://jsonplaceholder.typicode.com/users",
      "https://jsonplaceholder.typicode.com/posts",
    ];
    const responses = await Promise.all(urls.map((url) => axios.get(url)));
    const data = await Promise.all(responses.map((response) => response.data));
    console.log(data);
  } catch (error) {
    console.error(error);
  }
};

fetchApi();

In the example above, we're using Promise.all to fetch data from two different URLs at the same time. First, we create an array of URLs, then use the map to create an array of Promises from the axios.get calls. We pass this array to Promise.all, which returns an array of responses. Finally, we use the map again to get the data from each response and log it to the console.

How to Use Callbacks in TypeScript

A callback is a function passed as an argument to another function. The callback function is executed inside the other function. Callbacks ensure that a function doesn't run before a task is completed – but that it then runs right after the task finishes. They help us write asynchronous JavaScript code and prevent problems and errors.

// Example of using callbacks in typescript

const add = (a: number, b: number, callback: (result: number) => void) => {
  const result = a + b;
  callback(result);
};

add(10, 20, (result) => {
  console.log(result);
});

The image below shows the callback function:

Let's see another example of using callbacks in TypeScript:

// Example of using a callback function in TypeScript

type User = {
  name: string;
  email: string;
};

const fetchUserData = (
  id: number,
  callback: (error: Error | null, user: User | null) => void
) => {
  const api = `https://jsonplaceholder.typicode.com/users/${id}`;
  fetch(api)
    .then((response) => {
      if (response.ok) {
        return response.json();
      } else {
        throw new Error("Network response was not ok.");
      }
    })
    .then((data) => {
      const user: User = {
        name: data.name,
        email: data.email,
      };
      callback(null, user);
    })
    .catch((error) => {
      callback(error, null);
    });
};

// Usage of fetchUserData with a callback function
fetchUserData(1, (error, user) => {
  if (error) {
    console.error(error);
  } else {
    console.log(user);
  }
});

In the example above, we have a function called fetchUserData that takes an id and a callback as parameters. This callback is a function with two parameters: an error and a user.

The fetchUserData function retrieves user data from a JSONPlaceholder API endpoint using the id. If the fetch is successful, it creates an User object and passes it to the callback function with a null error. If there's an error during the fetch, it sends the error to the callback function with a null user.

To use the fetchUserData function with a callback, we provide an id and a callback function as arguments. The callback function checks for errors and logs the user data if there are no errors.

The image below shows the output of the API calls:

How to Use Callbacks Responsibly

While callbacks are fundamental to asynchronous programming in TypeScript, they require careful management to avoid "callback hell" – the pyramid-shaped, deeply nested code that becomes hard to read and maintain. Here's how to use callbacks effectively:

1. Avoid deep nesting

   • Flatten your code structure by breaking complex operations into named functions

   • Use promises or async/await for complex async workflows (more on this below)

2. Error handling first

   • Always follow the Node.js convention of (error, result) parameters

   • Check for errors at every level of nested callbacks

    function processData(input: string, callback: (err: Error | null, result?: string) => void) {
      // ... always call callback with error first
    }

3. Use type annotations

   • Leverage TypeScript's type system to enforce callback signatures

   • Define clear interfaces for callback parameters

    type ApiCallback = (error: Error | null, data?: ApiResponse) => void;

4. Consider control flow libraries
   For complex async operations, use utilities like async.js for:

   • Parallel execution

   • Series execution

   • Error handling pipelines

When to Use Callbacks vs. Alternatives

There are times when callbacks are a great choice, and other times when they’re not.

Callbacks are helpful when you’re working with async operations (single completion), interfacing with older libraries or APIs that expect callbacks, handling event listeners (like click listeners or websocket events) or creating lightweight utilities with simple async needs.

In other scenarios where you need to focus on writing maintainable code with a clear async flow, callbacks cause trouble and you should prefer promises or async-await. For example, when you need to chain multiple operations, handle complex error propagation, work with modern APIs (like the Fetch API or FS Promises), or use promise.all() for parallel execution.

Example migration from callbacks to promises:

// Callback version
function fetchUser(id: number, callback: (err: Error | null, user?: User) => void) {
  // ... 
}

// Promise version
async function fetchUserAsync(id: number): Promise<User> {
  // ...
}

// Usage with async/await
try {
  const user = await fetchUserAsync(1);
} catch (error) {
  // Handle error
}

The Evolution of Async Patterns

Modern TypeScript projects often use a mix: callbacks for event-driven patterns and promises/async-await for complex async logic. The key is choosing the right tool for your specific use case while maintaining code clarity.

Conclusion

In this article, we have learned about the different ways to handle asynchronous code in TypeScript. We have learned about callbacks, promises, async/await, and how to use them in TypeScript. We have also learned about this concept.

If you want to learn more about programming and how to become a better software engineer, you can subscribe to my YouTube channel CliffTech.

Thank you for reading my article. I hope you enjoyed it. If you have any questions, feel free to reach out to me.

Connect with me on social media:

• Twitter

• Github

• Linkedin

In this article, I'll give you a simple overview of how asynchronous programming works in Rust. You'll learn about futures as well as async/.await.

This article isn't a beginner's guide to Rust or asynchronous programming, so you'll need to have some experience with programming in Rust and familiarity with asynchronous programming to get the most out of this guide.

With that said, let's begin!

When Should You Use Asynchronous Programming?

Asynchronous tasks work like a more integrated version of threads. You can use them in a lot of the same scenarios where you can use multiple threads. The benefits async programming provides over multiple threads is that multi-threaded applications have a larger overhead to work on multiple tasks compared to asynchronous applications.

But this doesn’t make asynchronous applications better than multithreaded applications. Multi-threaded programs can run multiple computing-intensive tasks simultaneously – and multiple times faster than if you ran all the tasks in a single thread.

With asynchronous coding, trying to run multiple computing-intensive applications simultaneously will be much slower than just running every task on a single thread.

Asynchronous programming is very good for building applications that make many network requests or many IO operations like file reading and writing.

I can’t cover every case when you’ll want to use asynchronous techniques. But I can say that it’s most beneficial for tasks that have a lot of idle time (for example, waiting for a server to respond to a network request).

During the idle time of an asynchronous task, instead of blocking the thread, the event handler works on other tasks in the program until the asynchronous task is ready to make progress.

Overview of Asynchronous Rust – Futures

The basics of asynchronous Rust are Futures. Futures are similar to promises in JavaScript. They are Rust's way of saying "hey, I'm going to give you the result later, but just hold on to this (the future instance) to keep track of if the result is ready."

Futures are traits, with a poll state that is either Poll::Pending to signify that the future is in the process of executing its task, or Poll::Ready to signify that the future is done with its task.

Futures are lazy. They run when you .await them (we'll look into how to .await them in the next section). .awaiting a future pauses the execution of an asynchronous thread, and begins running its task. At this point the result of the poll method is Poll::Pending. When the future is done with its task, poll's state will become Poll::Ready, and the future will allow it's thread to proceed.

If you want to get more into the technical details about Futures, you can check out the documentation.

async/.await in Rust

async and .await are the primary ways you'll be working with asynchronous code in Rust. async is a keyword for declaring asynchronous functions. Within those functions, the .await keyword pauses its execution until the result of the future is ready.

Let's take a look at an example:

async fn add(a: u8, b: u8) -> u8 {
    a + b
}

async fn secondFunc() -> u8 {
    let a = 10;
    let b = 20;
    let result = add(a, b).await;
    return result;
}

Any asynchronous function declared with async fn wraps its return value in a future. On the third line of secondFunc, we .await the future from add(a, b) to get its result before proceeding to return it.

How to Work with Asynchronous Operations in main

Rust doesn’t allow you to async fn main functions. Running asynchronous operations from a non-asynchronous function may lead to some operations not fully concluding before the main thread is exited.

In this section, we’ll look at two ways solve this issue. The two ways to do this are with futures and tokio. Let's look at both.

tokio

tokio is a platform that provides tools and APIs for performing asynchronous applications. tokio also allows you to easily declare an asynchronous main function, which will help with the issue I described earlier.

To install tokio in your project, add this line to its Cargo.toml:

[dependencies]
tokio = { version = "1", features = ["full"] }

After adding the line, you can write your main functions like this:

async fn add(a: u8, b: u8) -> u8 {
    a + b
}

#[tokio::main]
async fn main() {
    let a = 10;
    let b = 20;
    let result = add(a, b).await;
    println!("{result}");
}

The futures library

futures is a library that provides methods for working with asynchronous Rust. For our use case, futures provides futures::executor::block_on(). This method works similar to .await in asynchronous functions. It blocks the main thread, until the result of future is ready. futures::executor::block_on() also returns the result of the completed future.

To install futures in your project, add this line to its Cargo.toml:

[dependencies]
futures = "0.3"

After installing the library, you can do something like this:

use futures::executor::block_on;

async fn add(a: u8, b: u8) -> u8 {
    a + b
}

fn main() {
    let a = 10;
    let b = 20;
    let result = block_on(add(a, b));
    println!("{result}"); 
}

First, we import the block_on method on the first line and use the method to block the main thread until the result of the add(a, b) function was ready. We also didn’t have to make the main function asynchronous like we did with tokio.

Conclusion

Asynchronous programming allows you to run operations in parallel and with less overhead and complexity compared to traditional multi-threading. In Rust, it allows you to build I/O and network applications more efficiently.

While this article should help you become familiar with the basics asynchronous programming in Rust, it’s still just an overview. There are some cases where you'll need to use other constructs in Rust like Pinning, Arcs, and so on.

If you have any questions or thoughts, feel free to reach out to me. Thanks for reading!

React Suspense is one such feature that has become quite popular among React devs.

In this guide, you'll learn all about React Suspense and examine its features, use cases, and potential to transform your web applications.

What is React Suspense?

React suspense is a new feature released in React.js version 16.6. With this new feature, components may pause rendering while they wait for an asynchronous process to finish, like separating code or retrieving data.

Suspense was created to make it easier for developers to create apps that have improved loading indications and a more cohesive user experience. It makes it possible to halt component tree rendering until specific criteria are satisfied, which makes it easier for developers to work with asynchronous data.

A Problem That Loading States Face in React

Managing loading states in React was a little trickier prior to React Suspense. Developers had to implement the loading mechanism using third-party frameworks like Redux or Mobx, conditional rendering, or state management. This frequently resulted in complicated, error-prone code.

This problem was solved by React Suspense, which offers a more sophisticated and integrated method of managing asynchronous actions and loading states.

Key Concepts and Features of React Suspense

Let's talk about some concepts and features to help you understand React Suspense and how it works.

1) Suspense Component

An essential element of React Suspense is the Suspense component. It lets you declare how to handle fallback content while asynchronous actions are pending and encapsulate any portion of your component tree.

<Suspense fallback={<LeoFallback />}>
  <LeoComponent />
</Suspense>

In this use case, if the LeoComponent is not ready, React will display the LeoFallback component instead.

2) Using React.lazy() or lazy()

React has a dynamic import mechanism called lazy() that lets you load components in a lazy manner.

Basically, lazy loading refers to the requirement that a component or portion of code will load only when it's needed. This functionality, which was first included in React 16.6, is frequently used in conjunction with React Suspense to enhance web application speed by loading components only when needed.

This is very helpful for minimizing your application's loading speed and lowering the initial bundle size.

Now we'll investigate lazy() in further depth and learn how it works.

Basic Syntax of lazy()

To use lazy(), you have to follow these steps:

First, import the Suspense components from React, as well as any components you intend to load lazily.

import { Suspense } from 'react';

Then use lazy() to define a dynamic import. For the component you wish to load slowly, this function accepts an argument that is a function that produces a dynamic import statement.

const LeoComponent = lazy(() => import('./LeoComponent'));

In this use case, the LeoComponent will be loaded lazily when it's needed. The dynamic import() statement specifies the path to the component you want to import.

Next, enclose the element you wish to load lazily in a Suspense element. You may designate a backup component to show while the lazy-loaded component is being retrieved by using the Suspense component.

function App() {
  return (
    <div>
      <Suspense fallback={<div>Loading...</div>}>
        <LeoComponent />
      </Suspense>
    </div>
  );
}

Here, while the LeoComponent is being fetched, the fallback component will be displayed, indicating that the content is loading.

Advantages of React.lazy()

1. Enhanced speed: By selectively loading the components needed for the current view and not loading all of the components at once, lazy loading of components can enhance the speed of the application.

2. Improved User Experience: You may improve the user experience by informing users that the application is actively loading material by utilizing Suspense to display a loading indication.

3. Code Splitting: One of lazy()'s main advantages is that it makes code splitting possible. The process of code splitting involves breaking up the code of your application into smaller, on-demand bundles. This minimizes the initial bundle size and quickens your application's loading time.

With lazy(), you can do code splitting and lazy loading of components in your React apps. This is a great feature. It is a useful tool for streamlining your web applications' efficiency and loading times, improving user experience by loading components only when needed.

It has restrictions and certain concerns, but when utilized properly, it may be a useful tool in your toolset for React development.

3) Error Boundaries

React components known as error boundaries have the ability to detect and manage faults inside their subtree. Because they can gently manage any problems that arise while waiting for asynchronous data, they are essential for dealing with suspense.

class ErrorBoundary extends React.Component {
  componentDidCatch(error, info) {
    // Handle the error
  }

  render() {
    return this.props.children;
  }
}

4) What is Concurrent Rendering?

React Suspense was introduced as part of Concurrent Mode, which is an experimental set of features in React. Later on, concurrent rendering was introduced.

Concurrent rendering enables the execution of numerous tasks at once, improving the responsiveness and efficiency of React apps. It is a component of Concurrent Mode, a trial-and-error collection of features designed to overcome some of the drawbacks of conventional React rendering.

Ensuring that the user interface stays fluid and responsive even when React is handling complicated rendering or other asynchronous operations is the core objective of concurrent rendering.

How Does React Suspense Work?

When using React Suspense with asynchronous operations, it follows these steps:

1. After React loads, a component tree is rendered.

2. React looks to see whether any of its child components are in a suspended state when it comes across a Suspense component.

3. React will display the given fallback UI until the data is ready, if a child component is awaiting data (for example, as a result of a lazy() import or a data fetch).

4. React smoothly transitions to rendering the real content once the data is available.

Because this procedure is automated, handling asynchronous actions without coding sophisticated logic is significantly easier for developers.

Use Cases for React Suspense

React Suspense is a flexible tool for your toolbox that may be used in a variety of scenarios, which include:

1. Data Fetching

React Suspense's data fetching feature makes managing asynchronous data loading in your React apps easier. React Suspense allows you to postpone rendering until the data is available, enhancing user experience by offering fallback content or loading indications.

I'll give an example using a fake API to show how to retrieve data using React Suspense.

Here's how to use React Suspense to manage data loading, assuming you're using a framework like React Query or Relay for data fetching:

Establish Error Boundary and React Suspense

To capture any failures during data retrieving, you must first set up an error boundary and a React Suspense component. Here's how to make a custom ErrorBoundary component in react for data fetching:

import React from 'react';

class ErrorBoundary extends React.Component {
  producer(props) {
    unique(props);
    this.state = { hasError: false };
  }

  static getDerivedStateFromError(error) {
    return { hasError: true };
  }

  render() {
    if (this.state.hasError) {
      return <div>Error: Something is wrong!</div>;
    }

    return this.props.children;
  }
}

export default ErrorBoundary;

Use React Query to Fetch Data

If you're using React Query to retrieve data, you can make a component that uses useQuery to retrieve data and wrap it in Suspense:

import React from 'react';
import { useQuery } from 'react-query';
import ErrorBoundary from './ErrorBoundary';

// Define your data-fetching function
async function fetchData() {
  const response = await fetch('https://api.example.com/data');
  if (!response.ok) {
    throw new Error('Network response was not ok');
  }
  return response.json();
}

function DataFetching() {
  const { data, isLoading, isError } = useQuery('data', fetchData);

  if (isLoading) {
    throw new Promise((resolve) => setTimeout(resolve, 2000)); // Simulate loading delay
  }

  if (isError) {
    throw new Error('Error while fetching data');
  }

  return (
    <div>
      <h1>Fetching data with React Suspense</h1>
      <p>{data}</p>
    </div>
  );
}

function App() {
  return (
    <div>
      <h1>Leo's App</h1>
      <ErrorBoundary>
        <React.Suspense fallback={<div>Loading...</div>}>
          <DataFetchingComponent />
        </React.Suspense>
      </ErrorBoundary>
    </div>
  );
}

export default App;

In this example, we fetch data using React Query's useQuery hook. To display the loading indicator, we throw in new Promise to mimic a loading delay if the data is still loading ( isLoading is true ). We throw an error so that the error boundary can catch it if there is a problem.

You can provide a backup component to display while loading by enclosing the DataFetching component in Suspense. It's a straightforward "Loading..." message in this instance.

You'll also want to ensure that the error handling, loading indications, and data fetching function are all customized according to your unique data-fetching needs.

This example shows how React Suspense makes state management and data fetching easier, leading to a more organized and understandable codebase.

These are examples of Suspense being used in a data fetching scenario in React.

2. Lazy Loading in React Suspense

Loading components of your application only when needed (lazy loading, also known as code splitting) can lower the size of your initial bundle and speed up the loading of your React application.

You can use React.lazy() in conjunction with React Suspense to easily include lazy loading into your application.

Here are the steps to implement lazy loading with React suspense:

First, import React Suspense from React:

import { Suspense } from 'react';

Next, create a lazy loaded component in your React app. To construct a component that loads slowly, use the React.lazy() method. Provide an arrow function to dynamically import the component.

const LennyComponent = lazy(() => import('./LennyComponent'));

Then wrap your component with a Suspense. Wrap Suspense around the sluggish part. While the lazy component is loading, you may designate a loading indication or fallback component to be shown.

function App() {
  return (
    <div>
      <h1>Leo's App</h1>
      <Suspense fallback={<div>Loading...</div>}>
        <LennyComponent />
      </Suspense>
    </div>
  );
}

The component can be used like any other component in your React application.

function LennyComponent() {
  return <div>This component is lazily loaded.</div>;
}

To finish building your application, you must use a development server and a tool like Webpack to build and serve your application in order to ensure that code splitting functions as intended. Your code will be automatically divided into pieces using Webpack for lazy loading.

This setup will minimize the initial bundle size and speed up the loading of your React application by only loading the LazyComponent when needed. While the component is being retrieved, users will see the loading indication (in this example, "Loading..."). The component loads and is rendered in the application with ease.

3. Better User Experiences

React Suspense can be employed to ensure a smooth user experience by showing loading indicators or fallback content during data loading. This reduces the perceived loading time for people who are using your React application.

For example, let's say you have a component that fetches data from an API using fetch and you want to display a loading spinner while the data is being fetched. Here's a basic example using React Suspense:

import React, { Suspense } from 'react';

// A component that fetches data
const fetchApiData = () => {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve('Data loaded!');
    }, 2000); // Simulating a 2-second delay for data fetching
  });
};

// A component that uses Suspense to handle asynchronous data fetching
const DataComponent = () => {
  const apidata = fetchApiData(); // This can be any async function, like an API call

  return <div>{apiData}</div>;
};

// Wrapping the component with Suspense
const App = () => {
  return (
    <Suspense fallback={<LoadingSpinner />}>
      <DataComponent />
    </Suspense>
  );
};

// A simple loading spinner component
const LoadingSpinner = () => {
  return <div>Loading...</div>;
};

In this instance:

The fetchApiData method is used by the DataComponent component to get data. Keep in mind that while fetchApiData is really a straightforward function that returns a promise, it may actually be an API call in practical applications.

The Suspense component, which requires a fallback argument, encapsulates the App component. One component that will be displayed while the asynchronous operation is running is the fallback prop. It's the LoadingSpinner component in this instance.

React Suspense will take care of the asynchronous data fetching automatically when the DataComponent is rendered. The LoadingSpinner component will render if the data is not yet accessible. After the data is retrieved, the user interface is updated.

This method eliminates the need for manual loading state management, making for a more seamless user experience. This code is straightforward and React Suspense works efficiently here.

Conclusion

React Suspense is a major addition to the React ecosystem. It provides a simpler, integrated method of managing asynchronous actions and loading states. You can use it to design apps that offer quicker loading times, more efficient data fetching, and better user experiences by utilizing Suspense, React.lazy(), and error boundaries.

It's critical to comprehend the capabilities, restrictions, and best practices of any strong instrument. Concurrent Mode and React Suspense have the power to revolutionize web application development and improve user experience even more. But as the React ecosystem continues to grow, it's imperative to keep up with the most recent advancements and industry best practices.

You write some promise-based code, everything is chugging along nicely, and then boom – one little promise rejects and the whole chain comes crashing down.

Your code grinds to a halt and you're left wondering why JavaScript couldn't just ignore that one little hiccup and continue on its merry way. Well, friend, do I have good news for you.

Meet Promise.allSettled(), your new best friend and the promise you never knew you needed. Promise.allSettled() is a game-changer, allowing you to wait for all your promises to settle – either resolve or reject – and then take action based on the results.

No more ruined promise chains or unhandled rejections. Just pure, unadulterated promise bliss. Join me as we dive into this little-known but incredibly useful promise method and see just how much it can simplify your asynchronous JavaScript code.

What Is Promise.allSettled()?

So you want to use JavaScript's Promise.allSettled() method, but aren't quite sure how it works or why you'd want to use it? No worries, I've got you covered.

Promise.allSettled() waits for all promises you give it to settle, meaning either resolve or reject. It then returns an array of objects with the status and value or reason for each promise.

This is useful when you have multiple asynchronous tasks that you want to ensure have completed, but don't necessarily care if some fail.

For example, say you have three API calls that return promises, and you want to get all the data back from the successful calls, even if one fails. You could do:

Promise.allSettled([apiCall1(), apiCall2(), apiCall3()]).then((results) => {});

This will run all three API calls, and the .then() callback will be called once they have all settled. The results array will have three objects: one for each promise, with either a status of 'fulfilled' and the data, or 'rejected' and the error.

We can filter to just get the successful calls, and proceed using that data.

The key things to remember are:

• Promise.allSettled() waits for all input promises to settle and returns their outcomes.
• Settled means either resolved (fulfilled) or rejected.
• It returns an array of objects with status and value/reason for each input promise.
• It allows handling successful promises even when some reject.

The problem with Promise.all() and the solution with Promise.allSettled()

Promise.all() is great when you want to wait for multiple promises to complete and get an array of all the resolved values. But it has one major downside: if any of the promises reject, the entire Promise.all() rejects immediately.

This can be problematic in some cases. For example, say you make requests to three different backend services, and you don't really care if one fails as long as the other two succeed. With Promise.all(), a single rejected promise would reject the entire group, and you'd miss the successful responses from the other promises.

Fortunately, there's a simple solution: Promise.allSettled(). This works similarly to Promise.all() but instead of rejecting immediately if any promise rejects, it waits for all promises to settle (either resolve or reject) and then returns an array of objects with the status and value/reason for each promise.

For example:

Promise.allSettled([
  Promise.resolve(1),
  Promise.reject(new Error("2")),
  Promise.resolve(3),
]).then((results) => {
  // results is an array of:
  // {status: "fulfilled", value: 1}
  // {status: "rejected", reason: Error}
  // {status: "fulfilled", value: 3}
});

As you can see, even though the second promise rejected, we still get the resolved values from the other promises. This allows you to handle rejections gracefully without missing any successful responses.

Promise.allSettled() provides more flexibility in these types of situations. You get the full picture of all your promises, regardless of some rejecting, so you have the opportunity to still make use of any resolved values and handle rejections appropriately.

So next time you need to wait on multiple promises but can't afford to miss any resolved values due to a rejection, be sure to reach for Promise.allSettled()! It's a very useful addition to the Promise API.

Common Questions About Promise.allSettled()

Will Promise.allSettled() slow down my code?

Not really. Promise.allSettled() simply waits for all the promises you pass to it to settle, either by fulfilling or rejecting. It doesn’t do anything else that would impact performance.

Can I still catch errors with Promise.allSettled()?

Yes, you absolutely can! Promise.allSettled() will give you the outcome of each promise, whether it was fulfilled or rejected.

For any rejected promises, you'll get the reason why it rejected, usually an error. You can catch these errors in the .catch() handler of the Promise.allSettled() call.

When should I use Promise.allSettled() vs Promise.all()?

Use Promise.allSettled() when you want to run multiple promises in parallel, but don’t want a single rejected promise to cause the entire group to reject.

For example, if you're fetching data from multiple third-party APIs, a rejected promise from one API shouldn’t stop you from getting data from the other APIs.

Use Promise.all() when you want to run promises in parallel but need them all to successfully complete for your code to continue.

For example, if you need to fetch data from two APIs to display on a page, you’d want both promises to fulfill before rendering the data.

Can I get the results of the settled promises?

Yes! Promise.allSettled() returns an array of objects with the status and value/reason for each promise. For example:

Promise.allSettled([
  Promise.resolve(1),
  Promise.reject(new Error("2")),
  Promise.resolve(3),
]).then((results) => {
  console.log(results);
  /*
    [
      { status: "fulfilled", value: 1 },
      { status: "rejected", reason: Error: 2 },
      { status: "fulfilled", value: 3 }
    ]
    */
});

You'll get information on all the promises, whether they fulfilled or rejected, so you have the full picture of the parallel operations.

Conclusion

So there you have it. Promise.allSettled() is a handy method you never knew you needed.

No longer do you have to wrap Promise.all() in a try/catch just to handle potential rejections. You can let Promise.allSettled() handle all that for you and just focus on the resolved values. Your async code will be cleaner and easier to read.

Thank you for reading. I am Rahul, 19, and a technical writer. Here is my proof of work.

JavaScript is a popular programming language used for developing interactive front-end web applications, among other things.

It's widely known for its major features: it is single-threaded, non-blocking, and asynchronous. But what do these three things mean?

What Does "Single-Threaded" Mean?

When a programming language is referred to as single-threaded, it means the language can execute only one instruction at a time. This differs from multi-threaded programming languages that run multiple instructions at once.

Illustration depicting Single-threaded and Multi-threaded processes

What Does "Non-Blocking" Mean?

When a programming language is said to be non-blocking, it means that the language does not wait for a specific previous instruction to finish executing before it moves to the next one. This ensures that no instruction blocks or obstructs the execution of subsequent instructions.

If a programming language is not non-blocking, it could lead to slow applications.

Illustration of JavaScript’s non-blocking behavior

What Does "Asynchronous" Mean?

JavaScript is also asynchronous (async), which means that it can handle a large number of tasks at a time. This is a feature of multi-threaded programming languages, but JavaScript achieves it with a single thread.

Illustration of the asynchronous process

Now, these features of JavaScript might seem contradictory. How can a language that is supposed to execute only one task at a time (Single-threaded) be able to handle a large number of tasks (asynchronous) simultaneously?

In this article, you will gain an understanding of how JavaScript manages to remain single-threaded despite executing asynchronous operations in the browser. We will also explore some concepts necessary for understanding the process.

This article assumes that you have basic knowledge of JavaScript and can apply it to Web Applications. The article covers the steps JavaScript takes to handle async operations in the browser. It does not go into detail to teach the different async functions there are, or how to write them. It only covers their process of execution in the browser.

The exciting part of all of this is that the article tells a short story, and uses this story as an analogy to explain the process. Through this unique approach, you will gain more insight into the inner workings of asynchronous operations.

Here's what we'll cover:

1. The story that will help explain these concepts
2. How the JavaScript engine works
3. How the call stack works
4. Asynchronous operations and web APIs
5. Callbacks
6. Callback queue
7. Event loops
8. Conclusion

The Story

This is the story of two companies. One of them is called Lerdorf Corp while the other is Eich Agency. These two companies are Event Planning Agencies and they cater to clients who need professional event planning services.

Lerdorf Corp is a long-running and successful company. They have a lot of staff and multiple specialized departments who work together to make sure they remain profitable. These departments include Catering, Registration and Ticketing, Accounting, and more.

When Lerdorf Corp secures a contract with a client, their efficient work process kicks into gear. The company swiftly breaks down the project into manageable tasks and assigns them to the respective departments responsible for their execution. This seamless division of labor ensures that each department can focus on its specific area of expertise, working in sync to deliver results.

This operational approach Lerdorf Corp employs is similar to how Multi-threaded Programming Languages function. In Multi-threaded programming, a program can be split into separate threads, with each executing independently of the others.

Returning to our story, let's now shift our focus to the Eich Agency. It's a small agency with limited staff. Despite their ambitious aspirations, it may seem quite laughable that they aim to compete with the well-established Lerdorf Corp.

Lerdorf Corp initially did not see them as a competition. They gave Eich Agency a month or two to move out of business. Eich Agency did not have any specialized departments. Yet, they were successfully able to execute big events, exactly the size one would think only Lerdorf Corp could pull off. Eich Agency’s client base also steadily expanded over time.

Lerdorf Corp did not understand how this could be the case. It was clear to them that Eich Agency did not have sufficient resources. They struggled to make sense of the situation and eventually held a meeting concerning the issue.

During the meeting, they decided to investigate how Eich Agency was able to execute events for clients so quickly without enough resources. Lerdorf decided to designate a capable staff member to conduct an extensive investigation of the agency and compile a comprehensive report within one week.

After one week, the report was completed, and the executive staff at Lerdorf Corp reviewed it together.

How the JavaScript Engine Works

With the investigation, it turned out that Eich Agency had a core team. The team received requests for planning events for clients. Now that team was responsible for most of the planning. They generated a blueprint for how an event would work out.

The Eich Agency team usually ordered the small tasks they needed to execute into a roadmap, then they'd start from the top to bottom, executing them in order. They did this because they did not have separate departments dedicated to a set of tasks like Lerdorf Corp.

JavaScript executes instructions similar to how Eich Agency does it. For a browser to interpret JavaScript code, it needs to have a JavaScript engine. This JavaScript engine is a software component of a modern web browser that accepts JavaScript code, analyzes it, and transforms it into instructions the device will understand. The JavaScript engine can be likened to the core team of Eich Agency.

JavaScript Engine inside the Runtime

The JavaScript runtime is the environment that contains all the resources necessary for the execution of a JavaScript program. It includes the JavaScript Engine but also includes other things we will look at.

Different browsers today use different JavaScript engines. For example, the Chrome Browser uses the V8 Engine from Google, Firefox uses one called Spidermonkey, and Opera Browser previously used the Carakan engine, before switching to V8.

These engines have individual differences, but their jobs still remain the same. They process JavaScript Code.

How the Call Stack Works

As the staff of Lerdorf Corp reviewed the report, they made an intriguing discovery. Eich Agency, upon finalizing the sequence of preparatory tasks for an upcoming event, would display the list on their board. With this order in place, the core team knew what task to start with and what to continue with.

The board Eich Agency uses to publicly list the order of tasks is similar to the Call Stack in the JavaScript Engine. The call stack is a component of a JavaScript Engine that keeps track of all the functions the program executes. It is a Stack data structure that operates with two key operations.

These operations are:

• Push: This operation adds or pushes a new function onto the top of the stack. The stack can only add new entries to the top.
• Pop: This operation removes or pops a new function off of the top of the stack. The Stack can only remove new entries from the top.

Last In First Out (LIFO) is a term that summarizes how the call stack works. The last operation that went in is the first operation that will leave the stack.

Simple Illustration of the Call Stack

After the JavaScript Engine receives JavaScript code, it parses the code and places the first function it encounters on the call stack. If, while executing that function, the JavaScript engine notices that it calls other functions, then those functions are stacked on top of the call stack. This is very important for functions nested in other functions as well as recursive functions.

The call stack makes it possible to track the current and future running functions essential for the execution of a program. For the stack to pop off a function, the engine must have finished interpreting and running that function. If not, it remains there. A peek at the JavaScript call stack during the execution of a program shows the current state of the program.

For example, consider these JavaScript instructions.

function greeting() {
    console.log("Hello World")
}

function run() {
    greeting()
}

run()

Upon execution of the code, the call stack can look something like this:

The Call Stack while monitoring functions

To recap, whenever the JavaScript engine receives code, it parses it and uses a call stack to monitor the execution of these instructions. This is similar to the way Eich Agency displays the order of tasks they need to accomplish.

Asynchronous Operations and Web APIs

The way the Eich Agency core team ordered the tasks they wanted to execute was not strange to Lerdorf Corp at all. They themselves as a company employed a similar strategy when they wanted to work for clients, but there were some distinctions.

In Lerdorf, whenever they got a contract, the first thing they did was break the task into a few smaller chunks. After they broke it down, they sent those chunks to different departments they had. They had a lot of departments and the process was faster if those departments started working on the tasks independently.

Lerdorf Corp already had each individual department with their own board similar to the one Eich Agency used. The departments used it to keep track of the tasks to accomplish.

Relating it to JavaScript terms, they had many “call stacks” that operated independently. Meanwhile, the Eich Agency had only one “call stack”.

This revelation puzzled the Lerdorf Corp team more. How then did Eich Agency manage to host large events properly if they pretty much had just a single department? This was the question on everyone’s mind.

Upon further review of the report, the Lerdorf team made a shocking discovery. They discovered that the core team at Eich Agency did not actually do all the work themselves. They did not have a Catering or Audio-Visual department, while these were departments Lerdorf Corp had.

But based on the contracts Eich Agency secured, they were typically expected to provide these services. When drafting their lists of tasks, they included the provision of these services, even though the agency could not provide them in-house.

Here's what they did instead: while executing their tasks, whenever Eich Agency encountered a task they could not immediately execute, they took action. They contacted a different company offering that specific service and requested help. After contacting the company, they returned to their order of tasks.

If, while following their list of tasks, they encountered another assignment that they couldn't perform, they repeated the process. They would find a separate service provider, discuss their needs with them, and request the required service.

Relating this to JavaScript, even though JavaScript is single-threaded, it is also asynchronous. In asynchronous programming, a language can execute multiple tasks simultaneously. Just like Eich Agency, whenever JavaScript encounters asynchronous instructions like requests to third-party sites, or timer-based actions, it seeks assistance.

To achieve this, JavaScript uses the browser’s provided Web Application Programming Interfaces (Web APIs).

One very important reason for writing asynchronous code is to prevent a scenario where a particular running function ends up blocking the rest of the code. If this happens, it can cause undesirable user experiences and make our software inefficient.

The Web APIs are a set of functions provided by the browser that the JavaScript engine can utilize. They include examples such as Document Object Model (DOM) manipulation methods, fetch, setInterval, setTimeout, promises, async-await functions, and more.

The JavaScript Engine interacting with the Web APIs

Callbacks

Let us briefly go back to the story of Lerdorf Corp and Eich Agency. Recall that Eich Agency contracted service providers and requested their assistance, and then continued with their order of execution.

Whenever any of the external service providers called back the agency to deliver a response, such as notifying the completion of a request, the agency would later act upon this new information.

Lerdorf Corp discovered that even though the external providers handled and completed many services, the agency's core team still needed to take further action.

For example, let's say the core team of Eich Agency had requested a catering service provider to supply a certain quantity of snacks and drinks. The core team would still be responsible for collecting the snacks from the caterers and incorporating them into their inventory of items for the event. In this scenario, the snacks would join other items that Eich Agency had prepared for the event.

This is similar to how JavaScript works in the browser. Asynchronous operations provide a response after being processed using Web APIs. The purpose of writing an asynchronous function is to utilize the function's output for subsequent operations. We refer to the functions that rely on the response from asynchronous operations as callback functions.

A callback function is a function that is passed as an argument to a parent function, which the parent function needs to invoke after completing its process. In JavaScript, asynchronous operations utilize callbacks to further process the responses they receive from Web APIs.

The example below is an asynchronous operation with a callback function.

button.addEventListener('click', function () {
    console.log('I was clicked!')
})

Now whenever the user clicks on the button, it triggers the callback function to fire. But the callback cannot happen unless the parent function calls or invokes it, which is dependent on the user's action.

You can also observe the use of callback functions with the fetch API.

fetch("<https://jsonplaceholder.typicode.com/users>")
.then((response) => response.json())
.then((response) => console.log(response))

In this example, the then method of the fetch object accepts an arrow function as an argument. The execution of this function is dependent on the response received from the fetch request, making it a callback function.

Also, in the second then method, you can see the usage of another callback. This is because the first callback returns another asynchronous function, necessitating the use of a callback.

To recap, a callback function is passed in as an argument to an asynchronous function and only runs when the asynchronous operation has been completed. This is similar to how Eich Agency only executes some tasks when their third-party vendors have called them back.

Callback Queue

Continuing their examination of Eich Agency’s execution process, the Lerdorf Corp team also discovered that Eich Agency often received multiple “call-backs” from the vendors they contacted. Each of these responses needed some action from the Eich Agency team.

Eich Agency streamlined its process further by keeping a separate list. This was a list where, whenever a vendor sent them a response they were supposed to act on, they would put that action inside the list.

This is what they did for every “call-back” they got. Eich Agency eventually ended up with a queue of extra tasks to perform but in a list separate from the one up on their board.

That list is similar to the Callback Queue in the browser’s JavaScript Runtime. The callback queue is a software mechanism that stores callback functions to be run after the Web APIs have processed asynchronous functions. It uses the queue data structure which works with the First In First Out (FIFO) approach. This means that the first callback added to that queue is going to be the first callback to leave.

JavaScript Runtime showing the Callback Queue

Event Loops

Eich Agency implemented one final step to make sure everything went well between them and their clients. They would wait until they completed the tasks on their initial board before addressing the queue of extra tasks.

Eich Agency designated a member of their core team to manage the queue of tasks. This team member would await the completion of the regular tasks by other team members. Once the initial tasks were cleared, the assigned team member would select the first item from the queue of extra tasks and display it on the board.

The core team would proceed to complete the assigned task, such as receiving the snack supplies from the vendors. Once accomplished, the team member responsible for managing the extra tasks would select the next item and add it to the board. The core team would then work towards achieving this task, and the process would repeat in a loop until all the items on the queue of extra tasks were exhausted.

The team member in charge of the extra tasks can be likened to the event loop in the browser’s JavaScript Runtime. The event loop is a loop that continuously checks if the call stack is empty. When the call stack is not empty, it allows the ongoing process to continue. But when the call stack becomes empty, the event loop fetches the task at the top of the callback queue and adds it to the call stack.

The event loop runs continuously as long as the program is running, always performing its function until the callback queue is completely empty. This is why the JavaScript Engine executes callbacks only after everything in the call stack has been processed.

For example, consider this code snippet.

console.log('A')
setTimeout(() => console.log('B'), 0)
console.log('C')

// A
// C
// B

It ends up logging A and C before B, even though the timeout was for 0 seconds. The reason for this is that the callback in setTimeout waited in the callback queue (setTimeout uses the Web API). The JavaScript Engine had to finish handling synchronous functions before handling the asynchronous ones. It needed the help of the event loop to send the callback function to the call stack.

The Event Loop in the JavaScript Runtime

To complete the story, after Lerdorf Corp understood how Eich Agency operated, they were impressed. They admired the way Eich Agency utilized its resources, but they immediately saw that it posed a threat to them and could potentially impact their business negatively.

Later on though, Lerdorf Corp realized that their client base differed from that of Eich Agency. While Eich Agency excelled in planning social events, Lerdorf Corp specialized in working with companies and organizing corporate events. There was no need for them to feel threatened by Eich Agency’s success. :)

Conclusion

In this article, you have learned various important concepts that illustrate the asynchronous nature of JavaScript.

We began by discussing the three fundamental characteristics of JavaScript – that it's single-threaded, that it's non-blocking, and that it's asynchronous – and acknowledged that they may initially appear contradictory. After that, we clarified this apparent misconception by explaining the details.

You learned some concepts like the JavaScript engine in the browser, the call stack, callbacks, the callback queue, and the event loop.

Additionally, we used a story as an analogy to enhance your understanding of these concepts further. With this, you should have gained a solid understanding of how asynchronous operations function in the browser.

But before we dive into that, we need to make sure you understand what Synchronous code is and how it works.

What is Synchronous Code?

When we write a program in JavaScript, it executes line by line. When a line is completely executed, then and then only does the code move forward to execute the next line.

Let's look at an example of this:

let greet_one = "Hello"
let greet_two = "World!!!"
console.log(greet_one)
for(let i=0;i<1000000000;i++){
}
console.log(greet_two);

Now if you run the above example on your machine you will notice that greet_one logs first. Then the program waits for a couple of seconds and then logs greet_two. This is because the code executes line by line. This is called synchronous code.

This creates lot of problems. For example, if a certain piece of code takes 10 seconds to execute, the code after it won't be able to execute until it's finished, causing delays.

What is Asynchronous Code?

With asynchronous code, multiple tasks can execute at the same time while tasks in the background finish. This is what we call non-blocking code. The execution of other code won't stop while an asynchronous task finishes its work.

Let's see an example of asynchronous code:

let greet_one = "Hello"
let greet_two = "World!!!"
console.log(greet_one)
setTimeout(function(){
    console.log("Asynchronous");
}, 10000)
console.log(greet_two);

In the above example, if you run the code on your machine you will see greet_one and greet_two logged even there is code in between those 2 logs.

Now, setTimeout is asynchronous so it runs in background, allowing code after it to execute while it runs. After 10 seconds, Asynchronous will print because we set a time of 10 seconds in setTimeout to execute it after 10 seconds.

In this tutorial, we will study asynchronous JavaScript in detail so you can learn how to write your own asynchronous code. I just wanted to give you a taste of async JavaScript using in-built functions to whet your appetite.

How Callbacks Work in JavaScript

"A callback function is a function passed into another function as an argument, which is then invoked inside the outer function to complete some kind of routine or action." (MDN)

Let's look at a code example to see why using callbacks instead would be helpful:

function compute(action, x, y){
    if(action === "add"){
        return x+y
    }else if(action === "divide"){
        return x/y
    }
}

console.log(compute("add",10,5))   
console.log(compute("divide",10,5))

In the above example, we have two operations. But what if we want to add more operations? Then the number of if/else statements would increase. This code would be lengthy, so we use callbacks instead:

function add(x,y){
    return x+y
}

function divide(x,y){
    return x/y
}

function compute(callBack, x, y){
    return callBack(x,y)
}

console.log(compute(add, 10, 5))    // 2
console.log(compute(divide, 10, 5))

Now when we call compute with three arguments, one of them is an operation. When we enter in the compute function, the function returns a function with a given action name. It, in response, calls that function and returns the result.

Welcome to Callback Hell

Callbacks are great, but you don't want to use them excessively. If you do, you'll get something called "callback hell". This happens when you nest callbacks within callbacks many levels deep.

The shape of callback hell is like a pyramid and is also called the “pyramid of doom”. It makes the code very difficult to maintain and understand. Here's an example of callback hell:

setTimeout(() =>{
    console.log("One Second");
    setTimeout(() =>{
        console.log("Two Seconds");
        setTimeout(() =>{
            console.log("Three Seconds");
            setTimeout(() =>{
                console.log("Four Seconds");
                setTimeout(() =>{
                    console.log("Five Seconds");
                }, 1000)
            }, 1000)
        }, 1000)
    }, 1000)
}, 1000)

When one second has passed, the code logs "one seconds". Then there's another call which runs after one more second and logs "two seconds" and it goes on and on.

We can escape this callback hell using something call Promises in asynchronous JavaScript.

How Promises Work in JavaScript

A promise is placeholder for the future result of an asynchronous operation. In simple words, we can say it is a container for a future value.

When using promises, we don't need to relay on callbacks which helps us avoid callback hell.

Before showing you how promises work through code, I'll explain promises using the analogy of a lottery ticket.

Promises are like lottery ticket. When we buy a lottery ticket, it says we will get money if our outcome is right. This is like a promise. The lottery draw happens asynchronously, and if the numbers match, we receive the money which was promised.

Now let's look at a code example:

const request = fetch('https://course-api.com/react-store-products')
console.log(request);

The above code is using fetch for a request from an API. It returns a promise which will get a response from the server.

This is how a promise looks. It has a particular promise state and result. When a promise is created it runs asynchronously. When the given task is completed, then we say the promise is settled. After the promise is settled, we can have either a fulfilled or rejected promise state based on the outcome of the promise. We can handle these different states in different ways in our code.

How to Consume Promises

We can consume a promise using the then() method on the promise. Producing code is code that can take some time to complete. Consuming code is code that must wait for the result.

So if we consume a promise, this means that when we make a request, we wait for the result. Then after result arrives, we perform some operation on those results.

Let's continue using the above example to understand how we can consume a promise.

const request = fetch('https://course-api.com/react-store-products').then((response) =>{
    console.log(response);
    return response.json()
}).then((data) =>{
    console.log(data);
})

We make a request to the country API. Then, after the fetch request, we use the then() method to consume the promise. After that, we return a bunch of information like header, status, and so on (you can see it in the below output image).

So we specifically need data which we need to convert to JSON which returns a promise. The data which is returned when we make a API request gets returned in the form of a promise.

To handle that promise, we again use the then() method to log data from the response. Using multiple then() methods on a single request is called chaining promises.

How to Handle Rejected Promises

Consuming promises is good and all, but it's also very important to learn how to handle rejected promises. In real world situations, there could be times when our app crashes due to not handling rejected promises properly.

So let's take an example: we will put our promises in a function called call(). In HTML, we will create a button and add an event listener to it. When we click on the button it will call the call() function.

Here's what that looks like:

index.html:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Promises</title>
</head>
<body>

    <button class="btn">Request</button>
    <script src="./script.js"></script>
</body>
</html>

script.js:

function call(){

    const request = fetch('https://course-api.com/react-store-products').then((response) =>{
        console.log(response);
        return response.json()
    }).then((data) =>{
        console.log(data);
    })

}

const btn = document.querySelector("button")
btn.addEventListener("click", function(){
    call();
})

Why are we doing this? We are setting the promise up to get rejected. Once we run this code, go to inspect and select the network tab. Set No throttling to offline and click on the button to send the request. You will get a rejected promise.

Once we click on the button, we will get error which is caused by no internet connection.

This situation can happen in the real world if a user's internet connection is slow. We are making an API request for which we need internet with decent speed. Sometimes the client might have an issue with their internet. This can lead to rejected promises which will throw an error which we haven't seen how to handle yet.

Now we will learn to handle this error. We used then() to consume our promises. Similar to that, we will chain the catch() method to that promise. Take a look at the following code:

function call(){

    const request = fetch('https://course-api.com/react-store-products').then((response) =>{
        console.log(response);
        return response.json()
    }).then((data) =>{
        console.log(data);
    }).catch((err) =>{
        alert(err);
    })

}

const btn = document.querySelector("button")
btn.addEventListener("click", function(){
    call();
})

Now the catch() method will get an error from the rejected promise and will display the message in an alert.

We get the error because we got a rejected promise which indicates that there is some issue. We can do whatever we want in the catch() block when we encounter an error.

Along with the catch() method, there is one more helpful method called finally(). We can chain it to promises which will run no matter whether the promise is accepted or rejected.

function call(){

    const request = fetch('https://course-api.com/react-store-products').then((response) =>{
        console.log(response);
        return response.json()
    }).then((data) =>{
        console.log(data);
    }).catch((err) =>{
        console.log(err);
    }).finally(() =>{
        console.log("Will always run");
    })

}

const btn = document.querySelector("button")
btn.addEventListener("click", function(){
    call();
})

We can use this finally() method for clearing things after the API call. There are many ways to use the finally() method.

How to Create a Promise

We know how to consume promises, but what about creating your own promises? You can do that using new Promise().

You might wonder - why do we need our own promises? Firstly, promises are asynchronous in nature. We can create any task to be asynchronous by creating our own promises. Wecan handle them using the then() and catch() methods that we learned in the above section.

Once you know how to create promises, you can make any piece of code asynchronous. Then it will not block code execution if the other code running is taking a long time to complete.

Let's see how this works using an example:

let lottery = new Promise(function(resolve, reject){
    console.log("Lottery is happening");

    setTimeout(() => {
        if(Math.random() >= 0.5){
            resolve("You Won!!!")
        }
        else{
            reject(new Error("Better luck next time"))
        }
    }, 5000);

})

First we created a promise using new Promise(). It will have a function with two arguments, resolve and reject.

We will call resolve when our task is successful, and reject when the task is unsuccessful. We will use the lottery terminology that I used to explain the concept of promises in the above section.

Let's say if Math.random() gives a value below or equal to 0.5, we will win the lottery. Otherwise we will lose the lottery. If the condition is not true, the code throws a new error for better understanding of the error in the console. So we can throw our own custom errors to the user for better understanding.

In the example above, if Math.random() is less than 0.5, that means the user lost the lottery. So we throw our custom error Better luck next time so that the user understands that they lost the lottery.

Now we will try to consume the promise that we created.

let lottery = new Promise(function(resolve, reject){
    console.log("Lottery is happening");

    setTimeout(() => {    
        if(Math.random() >= 0.5){
            resolve("You Won!!!")
        }
        else{
            reject(new Error("Better luck next time"))
        }   
    }, 5000);

})

lottery.then((response) =>{
    console.log(response);
}).catch((err) =>{
    console.log(err);
})

We consume the promise using the then() method. It will print the response that we provided in resolve(). If the promise is rejected we will catch the error in the catch() method. The error will come from the reject() argument that we mentioned in our own promise.

How to Consume Promises using Async/await

Consuming promises using the then() method can become messy sometimes. So we have an alternative method to consume promises called async/await.

Just keep in mind that async/await will be using the then() method behind the scenes to consume promises.

Why use async/await if we have the then() method? We use async/await because it's easy to use. If we start chaining methods to promises using the then() method the chain will be very long and gets complex with the addition of multiple then() methods. So async/await is simpler.

Here's how async/await works:

const fetchAPI = async function(){
    const res = await fetch('https://cat-fact.herokuapp.com/facts')
    const data = await res.json()
    console.log(data);
}
fetchAPI()
console.log("FIRST");

In the above code, we first call the fetchAPI() to see the async behavior of the function. Then it logs "FIRST". So according to asynchronous JavaScript, fetchAPI() should be running in the background and not block the execution of the code. As a result, "FIRST" logs and then the result of fetchAPI is displayed.

Now, if you want to handle asynchronous tasks in your functions, you have to make that function asynchronous using the async keyword before the function. Wherever promises are returned we have to use await before it to consume promises.

Now you might be thinking, how should we handle errors? For that we can use try...catch() to handle errors in async/await.

Error Handling with try...catch()

We can use try...catch() in vanilla JavaScript as well. But it can also help us handle errors in asynchronous JavaScript with async/await.

try...catch() is similar to the catch() method in then() using the catch() chaining method. Here we will try the code in the try block. If that runs successfully then there is no problem.

But if the code in the try block has an error, we can catch it in the catch block. We can check for errors in the try block and throw our custom error which will be caught in catch block. Once we catch the error in the catch block we can do whatever we want when we encounter an error.

Let's see how it works with the code example we've been using.

const fetchAPI = async function(){
    try{
        const res = await fetch('https://cat-fact.herokuapp.com/fact')
        if(!res.ok){
            throw new Error("Custom Error")
        }
        const data = await res.json()
        console.log(data);
    } catch(err){
        console.log(err);
    }
}


fetchAPI()
console.log("FIRST");

First, we wrap the asynchronous code in a try block. Then in the catch block we log the error. In the try block, if res.ok is false we throw our custom error using throw new Error which catch will get. Then we log it to the console.

How to Return Values from Async Functions

So far, we've learned about asynchronous code, the then() and catch() methods, and handling asynchronous code with async/await. But what if we want to return a value from an async function using async/await?

When you're working with asynchronous code, it's often necessary to return a value from an async function so that other parts of your program can use the result of the asynchronous operation.

For example, if you're making an HTTP request to fetch data from an API, you'll want to return the response data to the calling function so that it can be processed or displayed to the user.

Well, we can do that. Take a look at the below example:

const fetchAPI = async function(){
    try{
        const res = await fetch('https://cat-fact.herokuapp.com/facts')
        if(!res.ok){
            throw new Error("Custom Error")
        }
        const data = await res.json()
        console.log(data);
        return "Done with fetchAPI"
    } catch(err){
        console.log(err);
        throw new Error("Custom Error")
    }
}


console.log(fetchAPI())

If we log the fetchAPI we will get back a promise which is fullfilled. You know very well how to handle these promises. We will be doing it using the then() method.

const fetchAPI = async function(){
    try{
        const res = await fetch('https://cat-fact.herokuapp.com/facts')
        if(!res.ok){
            throw new Error("Custom Error")
        }
        const data = await res.json()
        console.log(data);
        return "Done with fetchAPI"
    } catch(err){
        console.log(err);
        throw new Error("Custom Error")
    }
}


fetchAPI().then((msg) =>{
    console.log(msg);
}).catch((err) =>{
    console.log(err);
})

Now when we run our program, we will see our returned msg from the try block using async/await logged in the console.

But what if there was an error in async/await? The fetchAPI with the then() method will still log it and it would be undefined.

To avoid this in the catch block again we throw a new error and use the catch() method to catch that error after the then() method.

Try changing the then() and catch() methods with async/await. This would be a good exercise for you to understand what you've learned in this article.

In JavaScript, there are two common ways to work with asynchronous operations: then/catch method chaining and async/await. Both methods can be used to handle promises, which are objects that represent the eventual completion (or failure) of an asynchronous operation.

then/catch method chaining is a more traditional way to handle asynchronous operations, while async/await is a newer syntax that provides a more concise and easier-to-read alternative.

How to Run Promises in Parallel

Let's say we want to make three requests for three different country capitals. We can do three different fetch calls, each of which will wait for the one above to complete.

const fetchAPI = async function(country1,country2,country3){
    try{
        const res1 = await fetch(`https://restcountries.com/v3.1/name/${country1}`)
        const res2 = await fetch(`https://restcountries.com/v3.1/name/${country2}`)
        const res3 = await fetch(`https://restcountries.com/v3.1/name/${country3}`)


        const data1 = await res1.json()
        const data2 = await res2.json()
        const data3 = await res3.json()
        console.log(data1[0].capital[0]);
        console.log(data2[0].capital[0]);
        console.log(data3[0].capital[0]);
        return "Done with fetchAPI"
    } catch(err){
        console.log(err);
        throw new Error("Custom Error")
    }
}


fetchAPI("canada", "germany", "russia")

In the above code, we are making three fetch calls, then converting them to json() and logging their capitals.

But if you hit inspect and see in the network tab, res2 is waiting for res1 to complete and res3 is waiting for res2 to complete.

This can negatively impact our application's performance. Because if a promise is waiting for another promise to complete it can negatively impact the performance of the website.

To overcome this performance issue, we can use something called **Promise.all** . It will call three fetch requests simultaneously, which in return will reduce our fetching time and improve our application's performance.

How to Use Promise.all()

With the help of Promise.all(), we can run multiple promises in parallel which will boost performance. The promise.all() takes an array as an argument which are promises and run them in parallel.

let promise1 = new Promise((resolve) =>{
    setTimeout(() =>{
       resolve("First Promise")
    }, 2000)
})

let promise2 = Promise.resolve("Second Promise")

let returnedPromises = Promise.all([promise1,promise2]).then((res) =>{
    console.log(res);
})

The result of using promise.all() is that both promises were running in parallel.

Wrapping Up

After reading this tutorial, I hope you have a better understanding of asynchronous JavaScript. Feel free to reach out to me for discussion and suggestions.

You can follow me on:

• Twitter

• LinkedIn

• Instagram

We'll start by giving a theoretical foundation about what asynchronism is, and how it relates to key components of JavaScript: The execution thread, the call stack and the event loop.

And then I'm going to present the three ways in which we can handle asynchronous tasks in JavaScript: Callbacks, promises and async/await.

Sounds fun, right? Let's go!

Table of Contents

• What is asynchronism

• Asynchronism in Javascript

  • What is the call stack?

  • Web APIs, the callback queue, and the event loop

    • What are Web APIs?

    • What are the callback queue and the event loop?

• So how do we code this stuff... ?

  • How callback functions work

  • How promises work

  • How async-await works

• Wrap-up

What is Asynchronism?

Any computer program is nothing but a series of tasks we require the computer to execute. In JavaScript, tasks can be classified into synchronous and asynchronous types.

Synchronous tasks are the ones that execute sequentially, one after the other, and while they're being executed nothing else is being done. At each line of the program, the browser waits for the task to finish before jumping to the next one.

We say this kind of tasks are "blocking", because while they execute they block the execution thread (I'm going to explain what this is in a sec), preventing it from doing anything else.

Asynchronous tasks, on the other hand, are the ones that, while they execute, they don't block the execution thread. So the program can still perform other tasks while the asynchronous task is being executed.

This is why we say this kind of tasks are "non blocking". This technique comes in handy specially for tasks that take long time to execute, as by not blocking the execution thread the program is able to execute more efficiently.

According to Mozilla docs:

Asynchronous programming is a technique that enables your program to start a potentially long-running task and still be able to be responsive to other events while that task runs, rather than having to wait until that task has finished. Once that task has finished, your program is presented with the result.

Asynchronism in JavaScript

Now that we have a more or less clear idea of what asynchronism is, let's get into the complicated interesting stuff – how JavaScript makes this possible.

One of the first apparent paradoxes of JavaScript – and there are a few – that you'll encounter when learning about the language is that JavaScript is a single threaded language.

"Single threaded" means it has a single thread of execution. This means that JavaScript programs can only execute a single task at a time.

This isn't the case, for example, for languages like Java or Ruby, which can create various execution threads and in that way execute many tasks simultaneously.

Visualizing single thread vs multi thread execution

And here the paradox is: if JavaScript can only execute only one task at a time, how come synchronous tasks can execute while asynchronous tasks complete "in the background"? How come asynchronous tasks don't block the execution thread? How are they executed then?

To explain this, we need to briefly describe how web browsers execute JavaScript code and some of its core components: The call stack, web APIs, the callback queue, and the event loop.

What is the Call Stack?

As you may now, a stack is a type of data structure where elements are added and removed following a LIFO (last in, first out) pattern. Browsers use something called the call stack to read and execute each task contained in a Javascript program.

Side comment: If you're not familiar with data structures, you can take a look at this article I wrote a while ago.

The way it works is quite simple. When a task is to be executed, it's added to the call stack. When it's finished, it's removed from the call stack. This same action is repeated for each and every task until the program is fully executed.

Let's see this with an easy example. If we had these three lines of code:

console.log('task 1')
console.log('task 2')
console.log('task 3')

Our call stack would look like this:

Illustration of an example call stack

1. Call stack starts off empty at the start of the program.

2. The first task is added to the call stack and executed.

3. The first task is removed from the call stack once finished.

4. The second task is added to the call stack and executed.

5. The second tasks is removed from the call stack once finished.

6. The third task is added to the call stack and executed.

7. The third task is removed from the call stack once finished. End of the program.

Easy right? Now let's see a slightly more complicated example with these lines of code:

const multiply = (a, b) => a*b

const square = n => multiply(n, n)

const printSquare = n => console.log(square(n))

printSquare(4)

Here we're calling printSquare(), which itself calls square(), which itself calls multiply(). With this program, our call stack might look like this:

Another more complex example of a call stack

1. Call stack starts off empty at the start of the program.

2. printSquare(4) is added to the call stack and executed.

3. As printSquare(4) calls the function square(4), square(4) is added to the call stack and executed as well. Note that as the execution of printSquare(4) isn't finished yet, it's kept on the stack.

4. As square(4) calls multiply(4,4), multiply(4,4) is added to the call stack and executed as well.

5. multiply(4,4) is removed from the call stack once finished.

6. square(4) is removed from the call stack once finished.

7. printSquare(4) is removed from the call stack once finished. End of the program.

In this example we can clearly see the LIFO pattern the call stack uses to add and remove tasks to it.

The important thing to notice here is that tasks are not removed from the stack until they're finished. This is how synchronous callbacks work.

When a function calls another function, the callback is added to the stack and executed. Once the execution of the callback is completed, it's removed from the stack and the execution of the main function is completed.

Web APIs, the Callback Queue, and the Event Loop

So far so good, right? Using the call stack, JavaScript takes account of each task, executes it, and then moves on to the next. Fairly simple.

Now let's check the following example:

console.log('task1')

setTimeout(() => console.log('task2'), 0)

console.log('task3')

Here, we're logging three separate strings, and on the second one we're using setTimeout to log it after 0 milliseconds. Which should be, according to common logic, instantly. So one should expect the console to log: "task1", then "task2", and then "task3".

But that's not what happens:

And if we had a look at our call stack during the program, It would look like this:

1. Call stack starts off empty at the start of the program.

2. console.log('task1') is added to the call stack and executed.

3. console.log('task1') is removed from the call stack once finished.

4. setTimeout(console.log('task2')) is added to the call stack, but it's not executed.

5. setTimeout(console.log('task2')) "mysteriously" disappears from the call stack.

6. console.log('task3') is added to the call stack and executed.

7. console.log('task4') is removed from the call stack once finished.

8. console.log('task2') "mysteriously" hops into the call stack and is executed.

9. console.log('task2') is removed from the call stack once finished.

To explain this "mysterious" disappearance and reappearance of the setTimeout task, we need to introduce three more components that are part of the browser runtime: Web APIs, the callback queue, and the event loop.

What are Web APIs?

Web APIs are a set of features and functionalities that the browser uses to enable JavaScript to execute. These features include DOM manipulation, AJAX calls, and setTimeout among other things.

To simplify the understanding of this, think about it like a different "execution place" rather than the call stack. When the call stack detects that the task it's processing is web API-related, it asks the web API "Hey API, I need to get this done", and the web API takes care of it, allowing the call stack to continue with the next task in the stack.

What are the callback queue and the event loop?

In the code example we saw before, we saw that setTimeout(console.log('task2')) "mysteriously" disappeared from the call stack. We now know that, it didn't actually disappear – it was sent to the web API.

But then it "mysteriously" reappeared again, so how does that work? Well, that's the job of the callback queue and the event loop.

The callback queue is a queue that stores the tasks that the web APIs return. Once the web API finishes executing the given task (which in this case was processing the setTimeout) it sends the callback to the callback queue.

Queues are a type of data structure where elements are added and removed following a FIFO pattern (first in, first out). Again, if you're not familiar with data structures, you can take a look at this article.

The event loop is a loop (woah... really?) that constantly checks two things:

1. If the call stack is empty

2. If there's any task present in the callback queue

If both of these conditions are met, then the task present in the callback queue is sent to the call stack to complete its execution.

Now that we know about web APIs, the callback queue, and the event loop, we can know what actually happened in our previous example:

Following the red lines, we can see that when the call stack identified that the task involved setTimeout, it sent it to the web APIs to process it.

Once the web APIs processed the task, it inserted the callback into the callback queue.

And once the event loop detected that the call stack was empty and that there was a callback present in the callback queue, it inserted the callback in the call stack to complete its execution.

This is how JavaScript makes asynchronism possible. Asynchronous tasks are processed by web APIs instead of the call stack, which handles only synchronous tasks.

In this way, the call stack can just derive asynchronous tasks to web APIs and carry on executing whatever else is present on the stack. And thanks to the callback queue and the event loop, once the asynchronous task was handled by the web APIs, the callback is reinserted into the call stack.

It's important to remember that JavaScript always runs only one task at a time. The "magic" of asynchronism is made possible by the existence of the web APIs, the callback queue, and the event loop, which are responsible for managing asynchronous tasks.

Side comment: If you wonder how all this works on Node instead of a browser, it's fairly similar. Instead of web APIs you have C++ APIs. The call stack, the callback queue, and the event loop work exactly the same.

If you want a more detailed explanation of all these topics, I recommend that you take a look at this very well known talk by Philip Roberts.

So How Do We Code This Stuff... ?

Now that we have the theoretical foundation of how JavaScript makes asynchronism possible, let's see how all this implements in code.

There are mainly three ways in which we can code asynchronism in JavaScript: callback functions, promises, and async-await.

I'll present them in the chronological order JavaScript has provided these features (first there were only callback functions, then came promises, and lastly async-await). But keep in mind that the most common and recommended practice nowadays is to use async-await. ;)

How Callback Functions Work

Callbacks are functions that are passed as arguments to other functions. The function that takes the argument is called a "Higher order function", and the function that is passed as an argument is called a "Callback".

We can see this in practice in the following example:

const callbackFunc = () => console.log('Im the callback')

const higherOrderFunction = callback => callback()

higherOrderFunction(callbackFunc)

Side comment: the possibility of passing functions as parameters to other functions is one of the features that make functions first class citizens in JavaScript.

The difference between synchronous and asynchronous callbacks relies on the type of task that function executes. There's no syntactic difference between each kind. Let's see this in code.

const arr = [1,2,3]

console.log('logging...')
arr.map(e => console.log('sync item', e)) // This is a synchronous callback

arr.map(e => setTimeout(() => console.log('async item', e), 0)) // This is an asynchronous callback
console.log('the stuff')

Here we have an array of three elements, a couple of console.logs, and two map functions. What map does is iterate over each element of the array and perform a function for each element in the array. That function is defined as a callback.

In the first map, we are logging the item with console.log. In the second one, we're doing the same but using setTimeout (which as we saw before is an asynchronous task performed by web APIs).

As a result, our console will look like this:

First, all the synchronous callbacks are executed, and then the asynchronous callbacks kick in.

As we can see, the fact that the functions execute asynchronously isn't related to the fact that they're callbacks or not, but rather to the kind of task that function executes. As setTimeout is an async task, those callbacks are executed asynchronously.

How Promises Work

A more modern approach for dealing with asynchronism is by using promises. A promise is a special kind of object in JavaScript that has 3 possible states:

• Pending: It's the initial state, and it signifies that the corresponding task is yet to be resolved.

• Fulfilled: Means the task has been completed successfully.

• Rejected: Means the task has produced some kind of error.

To see this in practice, we'll use a realistic case in which we fetch some data from an API endpoint and log that data in our console. We'll use the fetch API provided by browsers and a public API that returns Chuck Norris jokes.

Here our function executes a GET HTTP request to the endpoint, and we use the then and catch methods that the promise object has to process the promise response.

const fetchJokeWithPromises = () => {
    console.log('fetching with promises...')

    fetch('https://api.chucknorris.io/jokes/random')
        .then(res => res.json())
        .then(res => console.log('res', res))
        .catch(error => console.error('There was an error!', error))
}

fetchJokeWithPromises()

But let's take a closer look at this step by step.

• If we log just the fetch line, like this:

console.log('fetch', fetch('https://api.chucknorris.io/jokes/random'))

We see we get a promise with a pending state:

• Then if we execute the first then method and log its result, we get the following:

fetch('https://api.chucknorris.io/jokes/random')
    .then(res => console.log('res', res))

We see here we no longer have a promise, but the actual response from the endpoint. The then method waits for the promise to complete, and then provides us with the result, which is present as a parameter for the method.

• But to read the actual response body (which in our console we can see its a ReadableStream), we have to call the .json() method on it. This itself returns another promise. That's why we need another .then().

fetch('https://api.chucknorris.io/jokes/random')
        .then(res => res.json())
        .then(responseBody => console.log('responseBody', responseBody))

And here, finally we can see the full response and our joke in the value property. ;)

• What the catch method does is execute whenever a promise is rejected. Normally catch is used to handle an error, like showing a certain message to the user when an API fails to respond.

To see it in action, let's use a random endpoint like this one:

fetch('https://asdadsasdasd/')
    .then(res => res.json())
    .then(resp => console.log('resp', resp))
    .catch(error => console.error('There was an error!', error))

And in our console we can see the catch method executed:

An important thing to notice is in situations like this one, where we have various .then methods chained, we only need to use one .catch method. This is because that one .catch will process the errors in all of the promises chained.

Again, to see this in action now, let's go back to our previous endpoint and mess with the .json() call, misspelling it now.

fetch('https://api.chucknorris.io/jokes/random')
    .then(res => res.jon())
    .then(resp => console.log('resp', resp))
    .catch(error => console.error('There was an error!', error))

To round up promises, there's an additional method provided by promises which is .finally. This will execute always once the promise has been resolved, either successfully or not.

fetch('https://api.chucknorris.io/jokes/random')
    .then(res => res.json())
    .then(resp => console.log('resp', resp))
    .catch(error => console.error('There was an error!', error))
    .finally(() => console.log('Promised resolved!'))

How Async-Await Works

Async-await is the latest way of dealing with asynchronism provided by JavaScript. Basically, it's just syntactic sugar that allow us to deal with promises in a more concise way than using .then methods.

Let's see this in action following the same previous example.

const fetchJokeWithAsyncAwait = async () => {
    try {
        const res = await fetch('https://api.chucknorris.io/jokes/random')
        const data = await res.json()
        console.log('async-await data', data)

    } catch (error) {
        console.error('There was an error!', error)
    }
}

fetchJokeWithAsyncAwait()

Here we have a function that executes the fetch and logs the response. See that we start by using the async keyword when we declare the function. This is a requirement for all functions that use async-await.

Then we enclose our fetch call in a try-catch statement. This is required because with async-await we won't use the .catch method. But we still need to process possible errors.

We achieve this with the use of try-catch. If anything contained in the try statement returns an error, then the catch statement executes, obtaining the error as a parameter.

As you can see, we are assigning the result of the fetch call to a variable called res. And before the fetch we're using the await keyword.

const res = await fetch('https://api.chucknorris.io/jokes/random')

This means that Javascript will wait for the promise to resolve before assigning its value to the variable. And any operations done on that variable, will only execute once its value has been assigned.

In the next line we're calling the .json() method on the res variable, and again using the await keyword before it so the promise result is then assigned to the data variable.

And lastly, we log our data.

As mentioned, async-await is just syntactic sugar. It doesn't do anything differently than .then and .catch methods. It's just easier to write and read.

Wrap-up

Well everyone, as always, I hope you enjoyed the article and learned something new.

If you want, you can also follow me on LinkedIn or Twitter. See you in the next one!

This is because JavaScript is an asynchronous language...but what does that really mean? In this article, I hope to show you that the concept is not as difficult as it sounds.

Synchronous vs Asynchronous

Before we hop into the real deal, let's look at these two words – synchronous and asynchronous.

By default, JavaScript is a synchronous, single threaded programming language. This means that instructions can only run one after another, and not in parallel. Consider the little code snippet below:

let a = 1;
let b = 2;
let sum = a + b;
console.log(sum);

The above code is pretty simple – it sums two numbers and then logs the sum to the browser console. The interpreter executes these instructions one after another in that order until it is done.

But this method comes along with disadvantages. Say we wanted to fetch some large amount of data from a database and then display it on our interface. When the interpreter reaches the instruction that fetches this data, the rest of the code is blocked from executing until the data has been fetched and returned.

Now you might say that the data to be fetched isn't that large and it won't take any noticeable time. Imagine that you have to fetch data at multiple different points. This delay compounded doesn't sound like something users would want to come across.

Luckily for us, the problems with synchronous JavaScript were addressed by introducing asynchronous JavaScript.

Think of asynchronous code as code that can start now, and finish its execution later. When JavaScript is running asynchronously, the instructions are not necessarily executed one after the other as we saw before.

In order to properly implement this asynchronous behavior, there are a few different solutions developers has used over the years. Each solution improves upon the previous one, which makes the code more optimized and easier to understand in case it gets complex.

To further understand the asynchronous nature of JavaScript, we will go through callback functions, promises, and async and await.

What are Callbacks in JavaScript?

A callback is a function that is passed inside another function, and then called in that function to perform a task.

Confusing? Let's break it down by practically implementing it.

console.log('fired first');
console.log('fired second');

setTimeout(()=>{
    console.log('fired third');
},2000);

console.log('fired last');

The snippet above is a small program that logs stuff to the console. But there is something new here. The interpreter will execute the first instruction, then the second, but it will skip over the third and execute the last.

The setTimeout is a JavaScript function that takes two parameters. The first parameter is another function, and the second is the time after which that function should be executed in milliseconds. Now you see the definition of callbacks coming into play.

The function inside setTimeout in this case is required to run after two seconds (2000 milliseconds). Imagine it being carried off to be executed in some separate part of the browser, while the other instructions continue executing. After two seconds, the results of the function are then returned.

That is why if we run the above snippet in our program, we will get this:

fired first
fired second
fired last
fired third

You see that the last instruction is logged before the function in the setTimeout returns its result. Say we used this method to fetch data from a database. While the user is waiting for the database call to return results, the flow in execution will not be interrupted.

This method was very efficient, but only to a certain point. Sometimes, developers have to make multiple calls to different sources in their code. In order to make these calls, callbacks are being nested until they become very hard to read or maintain. This is referred to as Callback Hell

To fix this problem, promises were introduced.

What are Promises in JavaScript?

We hear people make promises all the time. That cousin of yours who promised to send you free money, a kid promising to not touch the cookie jar again without permission...but promises in JavaScript are slightly different.

A promise, in our context, is something which will take some time to do. There are two possible outcomes of a promise:

• We either run and resolve the promise, or

• Some error occurs along the line and the promise is rejected

Promises came along to solve the problems of callback functions. A promise takes in two functions as parameters. That is, resolve and reject. Remember that resolve is success, and reject is for when an error occurs.

Let's take a look at promises at work:

const getData = (dataEndpoint) => {
   return new Promise ((resolve, reject) => {
     //some request to the endpoint;

     if(request is successful){
       //do something;
       resolve();
     }
     else if(there is an error){
       reject();
     }

   });
};

The code above is a promise, enclosed by a request to some endpoint. The promise takes in resolve and reject like I mentioned before.

After making a call to the endpoint for example, if the request is successful, we would resolve the promise and go on to do whatever we want with the response. But if there is an error, the promise will get rejected.

Promises are a neat way to fix problems brought about by callback hell, in a method known as promise chaining. You can use this method to sequentially get data from multiple endpoints, but with less code and easier methods.

But there is an even better way! You might be familiar with the following method, as it's a preferred way of handling data and API calls in JavaScript.

What is Async and Await in JavaScript?

The thing is, chaining promises together just like callbacks can get pretty bulky and confusing. That's why Async and Await was brought about.

To define an async function, you do this:

const asyncFunc = async() => {

}

Note that calling an async function will always return a Promise. Take a look at this:

const test = asyncFunc();
console.log(test);

Running the above in the browser console, we see that the asyncFunc returns a promise.

Let's really break down some code now. Consider the little snippet below:

const asyncFunc = async () => {
    const response = await fetch(resource);
       const data = await response.json();
}

The async keyword is what we use to define async functions as I mentioned above. But how about await ? Well, it stalls JavaScript from assigning fetch to the response variable until the promise has been resolved. Once the promise has been resolved, the results from the fetch method can now be assigned to the response variable.

The same thing happens on line 3. The .json method returns a promise, and we can use await still to delay the assigning until the promise is resolved.

To Block Code or Not to Block Code

When I say 'stalling', you must think that implementing Async and Await somehow blocks code execution. Because what if our request takes too long, right?

Fact is, it doesn't. Code that is inside the async function is blocking, but that doesn't affect program execution in any way. The execution of our code is just as asynchronous as ever. To show this,

const asyncFunc = async () => {
    const response = await fetch(resource);
       const data = await response.json();
}

console.log(1);
cosole.log(2);

asyncFunc().then(data => console.log(data));

console.log(3);
console.log(4);

In our browser console, the output of the above would look something like this:

1
2
3
4
data returned by asyncFunc

You see that as we called asyncFunc, our code continued running until it was time for the function to return results.

Conclusion

This article does not treat these concepts in great depth, but I hope it shows you what asynchronous JavaScript entails and a few things to look out for.

It is a very essential part of JavaScript, and this article only scratches the surface. Nonetheless, I hope this article helped to break down these concepts.

Over the last 18 years of programming, I've had to deal with asynchronous behavior in virtually every project.

Since the adoption of async-await in JavaScript, we've learned that async-await makes a lot of code more pleasant and easier to reason about.

Recently I noticed that when I work with a resource that needs to asynchronously connect and disconnect, I end up writing code like this:

// NOT MY FAVORITE PATTERN
router.get('/users/:id', async (req, res) => {
  const client = new Client();
  let user;
  try {
    await client.connect();
    user = await client.find('users').where('id', req.path.id);
  } catch(error) {
    res.status(500);
    user = { error };
  } finally {
    await client.close();
  }
  res.json(user);
});

It gets verbose because we have to use try/catch to handle errors.

Examples of such resources include databases, ElasticSearch, command lines, and ssh.

In those use cases, I've settled into a code pattern I'm calling the Result-Error Pattern.

Consider rewriting the code above like this:

// I LIKE THIS PATTERN BETTER
router.get('/users/:id', async (req, res) => {
  const { result: user, error } = await withDbClient(client => {
    return client.find('users').where('id', req.path.id);
  });
  if (error) {
    res.status(500);
  }
  res.json({ user, error });
});

Notice a few things:

1. The database client gets created for us and our callback can just utilize it.
2. Instead of capturing errors in a try-catch block, we rely on withDbClient to return errors.
3. The result is always called result because our callback may return any kind of data.
4. We don't have to close the resource.

So what does withDbClient do?

1. It handles creating the resource, connecting and closing.
2. It handles try, catch, and finally.
3. It ensures that there will be no uncaught exceptions thrown from withDbClient.
4. It ensures that any exceptions thrown in the handler also get caught inside withDbClient.
5. It ensures that { result, error } will always be returned.

Here is an example implementation:

// EXAMPLE IMPLEMENTATION
async function withDbClient(handler) {
  const client = new DbClient();
  let result = null;
  let error = null;
  try {
    await client.connect();
    result = await handler(client);
  } catch (e) {
    error = e;
  } finally {
    await client.close();
  }
  return { result, error };
}

A step further

Photo by Tom Fisk from Pexels

What about a resource that does not need to be closed? Well the Result-Error Pattern can still be nice!

Consider the following use of fetch:

// THIS IS NICE AND SHORT
const { data, error, response } = await fetchJson('/users/123');

Its implementation might be the following:

// EXAMPLE IMPLEMENTATION
async function fetchJson(...args) {
  let data = null;
  let error = null;
  let response = null;
  try {
    const response = await fetch(...args);
    if (response.ok) {
      try {
        data = await response.json();
      } catch (e) {
        // not json
      }
    } else {
      // note that statusText is always "" in HTTP2
      error = `${response.status} ${response.statusText}`;
    }
  } catch(e) {
    error = e;  
  }
  return { data, error, response };
}

Higher-level use

Photo by 16018388 from Pixabay

We don't have to stop at low-level use. What about other functions that may end with a result or error?

Recently, I wrote an app with a lot of ElasticSearch interactions. I decided to also use the Result-Error pattern on higher-level functions.

For instance, searching for posts produces an array of ElasticSearch documents and returns result and error like this:

const { result, error, details } = await findPosts(query);

If you've worked with ElasticSearch, you'll know that responses are verbose and data is nested several layers inside the response. Here, result is an object containing:

1. records – An Array of documents
2. total – The total number of documents if a limit was not applied
3. aggregations – ElasticSearch faceted-search information

As you might guess, error may be an error message and details is the full ElasticSearch response in case you need things like error metadata, highlights, or query time.

My implementation for searching ElasticSearch with a query object reads something like this:

// Fetch from the given index name with the given query
async function query(index, query) {
  // Our Result-Error Pattern at the low level  
  const { result, error } = await withEsClient(client => {
    return client.search({
      index,
      body: query.getQuery(),
    });
  });
  // Returning a similar object also with result-error
  return {
    result: formatRecords(result),
    error,
    details: result || error?.meta,
  };
}

// Extract records from responses 
function formatRecords(result) {
  // Notice how deep ElasticSearch buries results?
  if (result?.body?.hits?.hits) {
    const records = [];
    for (const hit of result.body.hits.hits) {
      records.push(hit._source);
    }
    return {
      records,
      total: result.body.hits.total?.value || 0,
      aggregations: result.aggregations,
    };
  } else {
    return { records: [], total: null, aggregations: null };
  }
}

And then the findPosts function becomes something simple like this:

function findPosts(query) {
  return query('posts', query);
}

Summary

Here are the key aspects of a function that implements the Result-Error Pattern:

1. Never throw exceptions.
2. Always return an object with the results and the error, where one may be null.
3. Hide away any asynchronous resource creation or cleanup.

And here are the corresponding benefits of calling functions that implement the Result-Error Pattern:

1. You don't need to use try-catch blocks.
2. Handling error cases is as simple as if (error).
3. You don't need to worry about setup or cleanup operations.

Don't take my word for it, try it yourself!

Noodling about on Discord today, the same question came up a few times on a few different servers. I thought it was a great question, and it seems my brain doesn't work quite the way others might expect.

Here's the question:

"So I have a fetch function, and I'm doing some then along with it to parse out the JSON data. I want to return that, but how can I? We can't return something from an asynchronous function call!"

That's a great question. There's a lot going on there. We have ways of handling this within React, quite easily: we can useState to create some stateful variable, we can run our fetch within a useEffect and load that stateful variable, and we can use another useEffect to listen for that stateful variable to change. When the change happens, we can trigger our custom function and do some sort of side-effect with it.

With pure JavaScript, HTML, and CSS, it becomes a tad bit more tricky. For those who like to read the last page of the mystery novel before the rest, this replit is where we'll end up.

An Ugly Beginning

Suppose we want to fetch some todos from a server, and when we've loaded them we want to update the DOM. We might need to reload them, or append to them later – we want things to happen if our asynchronous functions do some sort of update to our state.

And yet, I don't really know how I feel about that. When we have a block of code like this:

const load = () => {
  fetch("https://jsonplaceholder.typicode.com/todos")
    .then(res => res.json())
    .then(jsonObj => {
      const todoContainer = document.querySelector(".todos-container");
      // now, take each todo, create its DOM, and poke it in.
      jsonObj.forEach( (todo)=>{
        const todoEl = document.createElement("div");
        todoEl.classList.add("todo");
        const todoTitle = document.createElement("h3");
        todoTitle.classList.add("todo-title");
        todoTitle.textContent=todo.title;

        const todoStatus = document.createElement("div");
        todoStatus.classList.add("todo-status");
        todoStatus.textContent = todo.done ? "Complete" : "Incomplete";

        todoEl.append(todoTitle, todoStatus);
        todoContainer.append(todoEl)
    })
}

We kind of have to fill the DOM right there in the .then() block, because we can't really say "hey, when this is done, fire off this function."

We could simply await each of the Promises, rather than chaining them like this, and simply return the result of the final parsing:

const load = async () => {
  const result = await fetch("https://jsonplaceholder.typicode.com/todos")
  const jsonObj = await result.json();
  const todoContainer = document.querySelector(".todos-container");

  jsonObj.forEach( (todo)=>{
    const todoEl = document.createElement("div");
    todoEl.classList.add("todo");
    const todoTitle = document.createElement("h3");
    todoTitle.classList.add("todo-title");
    todoTitle.textContent=todo.title;

    const todoStatus = document.createElement("div");
    todoStatus.classList.add("todo-status");
    todoStatus.textContent = todo.done ? "Complete" : "Incomplete";

    todoEl.append(todoTitle, todoStatus);
    todoContainer.append(todoEl)
  })
  // here, if we wanted, we could even return that object:
  return jsonObj;
}

// later, we can do this:
const todos = await load();
// fills the DOM and assigns all the todos to that variable

Now that is better, our load() function can be used to not only put those elements into the DOM, but it returns the data to us.

This is still not ideal, though – we are still having to fill that DOM when the result is loading, and we still have to wait for the loading to happen. We have no idea when todos is going to be something. Eventually, it will be, but we don't know when.

Callbacks, Anyone?

We do have the option of a callback function. It might be useful, instead of actually hard-coding the DOM construction stuff, to pass that off to something else. It makes the load function more abstract, as it isn't wired to a particular endpoint.

Let's see what that might look like:

const load = async (apiEndpoint, callbackFn) => {
  const result = await fetch(apiEndpoint);
  if(!result.ok){
    throw new Error(`An error occurred: ${result.status}`)
  }
  // at this point, we have a good result:
  const jsonObj = await result.json();
  // run our callback function, passing in that object
  callbackFn(jsonObj)
}

// Let's use that. First, we'll make a callback function:
const todoHandler = (todos) => {
  const todoContainer = document.querySelector(".todos-container");

  todos.forEach( (todo)=>{
    const todoEl = document.createElement("div");
    todoEl.classList.add("todo");
    const todoTitle = document.createElement("h3");
    todoTitle.classList.add("todo-title");
    todoTitle.textContent=todo.title;

    const todoStatus = document.createElement("div");
    todoStatus.classList.add("todo-status");
    todoStatus.textContent = todo.done ? "Complete" : "Incomplete";

    todoEl.append(todoTitle, todoStatus);
    todoContainer.append(todoEl)
  })    
}

load("https://jsonplaceholder.typicode.com/todos", todoHandler);

That's nicer – we are now telling load what to load, and what to do when that fetch has completed. It works. And there isn't anything really wrong with that. Still, it has some drawbacks.

My callback is by no means complete. We aren't handling errors, we aren't really gaining anything by this approach. We don't get the data out of the load function in any sense we can use, in a timely fashion.

And again, me being me, I wanted to try a different way.

Callbacks Without Callbacks

Okay, that is a little misleading. They're not callbacks. We are going to completely avoid having callbacks at all. What will we have instead? Event listeners!

The DOM is all about communication. Events fire off all over the place – mouse events, keyboard events, gestures and media and window... The browser is a noisy place.

But it is all controlled, it is all intent-ful and it is all well-formed. Things are encapsulated nicely, completely self-contained, but they can communicate events up and down the DOM tree as needed. And we can leverage that, with the CustomEvent API.

Creating a CustomEvent is not really that difficult, simply provide the name of the event as a string, and the payload – the information to be included in that event. Here's an example:

const myShoutEvent = new CustomEvent('shout', {
  detail: {
    message: 'HELLO WORLD!!',
    timeSent: new Date() 
  }
})

// and later on, we can send that event:
someDomEl.dispatchEvent(myShoutEvent);

That's all there is to a custom event. We create the event, including custom detail data, and then we dispatchEvent on a given DOM node. When that event is fired on that DOM node, it joins the normal stream of communication, riding along on the bubbling and capturing phases just like any normal event – because it is a normal event.

How does this help us?

What if we were to listen for that custom event somewhere, and place the responsibility for handling that event (and its detail) with the receiver, rather than telling the load function what to do when we get that data?

With this approach, we don't really care when the fetch completes its processing, we don't care about some returning value in some global variable – we simply tell the DOM node to dispatch an event... and pass along the fetched data as detail.

Let's start playing with this idea:

const load = (apiEndpoint, elementToNotify, eventTitle) => {
  fetch(apiEndpoint)
    .then( result => result.json() )
    .then( data => {
       // here's where we do this: we want to create that custom event
       const customEvent = new CustomEvent(eventTitle, {
         detail: {
           data
         }
       });
       // now, we simply tell the element to do its thing:
      elementToNotify.dispatchEvent(customEvent)
     })
};

That's it. That's the whole shebang. We load some endpoint, we parse it, we wrap the data in a custom event object, and we throw it out into the DOM.

The rest is outside of the concern of that load function. It doesn't care about what the data looks like, it doesn't care where it's coming from, it doesn't return anything. It does this one thing – fetch data and then yell about it.

Now, with that in place, how might we wire that in from the other side?

// a function to create the Todo element in the DOM...
const createTodo = ({id, title, completed}) => {
  const todoEl = document.createElement("div");
  todoEl.classList.add("todo");

  const todoTitle = document.createElement("h3");
  todoTitle.classList.add("todo-title");
  todoTitle.textContent=todo.title;

  const todoStatus = document.createElement("div");
  todoStatus.classList.add("todo-status");
  todoStatus.textContent = todo.done ? "Complete" : "Incomplete";

  todoEl.append(todoTitle, todoStatus);

  return todoEl;
}

// and when that load event gets fired, we want this to be
//  the event listener.
const handleLoad = (event)=>{
  // pull the data out of the custom event...
  const data = event.detail.data;
  // and create a new todo for each object
  data.forEach( todo => {
    event.target.append( createTodo(todo) )
  })
}

// finally, we wire in our custom event!
container.addEventListener("todo.load", handleLoad)

That wires up the container to listen for that custom todo.load event. When the event happens, it fires off and executes that handleLoad listener.

It isn't doing anything particularly magic: it simply gets the data from that event.detail we create in the load function. Then the handleLoad calls the createTodo for each object in the data, creating our DOM node for each todo element.

Using this approach, we have nicely separated the data-fetching bits from the presentation bits. The only thing remaining is telling the one to talk to the other:

// remember, the parameters we defined were:
// apiEndpoint: url,
// elementToNotify: HTMLDomNode,
// eventTitle: string
load("https://jsonplaceholder.typicode.com/todos", container, 'todo.load');

To Recap

We started with an ugly spaghetti-code mess – fetching logic mixed in with parsing and presentation. No good. I mean, we all do it, we use it all the time, but it just feels sketchy. There is no clean separation, and there is no way of working with the data outside of that .then().

Using async/await, we can return that data, and we can use it outside the fetch if we need – but we have no real way of knowing when that data has been loaded. We can still process inline, loading the presentational layer in with the fetch, but that's no gain from the last.

Using callbacks, we can begin to separate – with a callback, we can load the data and, when the asynchronous operation is done, run the callback function. It does keep them nicely separated and it does pass the data into the callback as a parameter. It is better than mixing the presentation inline, but we can do something different.

And I mean that different – using the CustomEvent API is no better or worse than using callbacks. Both have their strengths and weaknesses. I like the clean-ness of the CustomEvent system, I like that we can extend that out. Some examples:

• a Timer class, that fires off a "timer.tick" and "timer.complete" event. The parent/container of that Timer's DOM node can listen for those events, firing asynchronously, and respond appropriately, whether updating the displayed time or causing a reaction when the timer's done.
• our Todos – we could have the container listen for "todo.load", "todo.update", whatever custom events we like. We could handle updates by finding the relevant DOM node and updating its content, or removing all and replacing them on a load.

We are separating the model logic from the presentation logic entirely, and defining an interface between the two. Clean, clear, reliable and simple.

JavaScript is a single-threaded, non-blocking, asynchronous, concurrent programming language with lots of flexibility.

Hold on a second – did it say single-threaded and asynchronous at the same time? If you understand what single-threaded means, you'll likely mostly associate it with synchronous operations. How can JavaScript be asynchronous, then?

In this article, we will learn all about the synchronous and asynchronous parts of JavaScript. You use both in web programming almost daily.

If you like to learn from video content as well, this article is also available as a video tutorial here: 🙂

In this article, You'll Learn:

• How JavaScript is synchronous.
• How asynchronous operations occur when JavaScript is single-threaded.
• How understanding synchronous vs. asynchronous helps you better understand JavaScript promises.
• Lots of simple but powerful examples to cover these concepts in detail.

JavaScript Functions are First-Class Citizens

In JavaScript, you can create and modify a function, use it as an argument, return it from another function, and assign it to a variable. All these abilities allow us to use functions everywhere to place a bunch of code logically.

Lines of code organized into functions logically

We need to tell the JavaScript engine to execute functions by invoking them. It'll look like this:

// Define a function
function f1() {
    // Do something
    // Do something again
    // Again
    // So on...
}

// Invoke the function
f1();

By default, every line in a function executes sequentially, one line at a time. The same is applicable even when you invoke multiple functions in your code. Again, line by line.

Synchronous JavaScript – How the Function Execution Stack Works

So what happens when you define a function and then invoke it? The JavaScript engine maintains a stack data structure called function execution stack. The purpose of the stack is to track the current function in execution. It does the following:

• When the JavaScript engine invokes a function, it adds it to the stack, and the execution starts.
• If the currently executed function calls another function, the engine adds the second function to the stack and starts executing it.
• Once it finishes executing the second function, the engine takes it out from the stack.
• The control goes back to resume the execution of the first function from the point it left it last time.
• Once the execution of the first function is over, the engine takes it out of the stack.
• Continue the same way until there is nothing to put into the stack.

The function execution stack is also known as the Call Stack.

Function Execution Stack

Let's look at an example of three functions that execute one by one:

function f1() {
  // some code
}
function f2() {
  // some code
}
function f3() {
  // some code
}

// Invoke the functions one by one
f1();
f2();
f3();

Now let's see what happens with the function execution stack:

A step-by-step flow shows the execution order

Did you see what happened there? First, f1() goes into the stack, executes, and pops out. Then f2() does the same, and finally f3(). After that, the stack is empty, with nothing else to execute.

Ok, let's now work through a more complex example. Here is a function f3() that invokes another function f2() that in turn invokes another function f1().

function f1() {
  // Some code
}
function f2() {
  f1();
}
function f3() {
  f2();
}
f3();

Let's see what's going on with the function execution stack:

A step-by-step flow shows the execution order

Notice that first f3() gets into the stack, invoking another function, f2(). So now f2() gets inside while f3() remains in the stack. The f2() function invokes f1(). So, time for f1() to go inside the stack with both f2() and f3() remaining inside.

First, f1() finishes executing and comes out of the stack. Right after that f2() finishes, and finally f3().

The bottom line is that everything that happens inside the function execution stack is sequential. This is the Synchronous part of JavaScript. JavaScript's main thread makes sure that it takes care of everything in the stack before it starts looking into anything elsewhere.

Great! Now that we understand how synchronous operations work in JavaScript, let's now flip the coin and see its asynchronous side. Are you ready?

Asynchronous JavaScript – How Browser APIs and Promises Work

The word asynchronous means not occurring at the same time. What does it mean in the context of JavaScript?

Typically, executing things in sequence works well. But you may sometimes need to fetch data from the server or execute a function with a delay, something you do not anticipate occurring NOW. So, you want the code to execute asynchronously.

In these circumstances, you may not want the JavaScript engine to halt the execution of the other sequential code. So, the JavaScript engine needs to manage things a bit more efficiently in this case.

We can classify most asynchronous JavaScript operations with two primary triggers:

1. Browser API/Web API events or functions. These include methods like setTimeout, or event handlers like click, mouse over, scroll, and many more.
2. Promises. A unique JavaScript object that allows us to perform asynchronous operations.

Don't worry if you are new to promises. You do not need to know more than this to follow this article. At the end of the article, I have provided some links so you can start learning promises in the most beginner-friendly way.

How to Handle Browser APIs/Web APIs

Browser APIs like setTimeout and event handlers rely on callback functions. A callback function executes when an asynchronous operation completes. Here is an example of how a setTimeout function works:

function printMe() {
  console.log('print me');
}

setTimeout(printMe, 2000);

The setTimeout function executes a function after a certain amount of time has elapsed. In the code above, the text print me logs into the console after a delay of 2 seconds.

Now assume we have a few more lines of code right after the setTimeout function like this:

function printMe() {
  console.log('print me');
}

function test() {
  console.log('test');
}

setTimeout(printMe, 2000);
test();

So, what do we expect to happen here? What do you think the output will be?

Will the JavaScript engine wait for 2 seconds to go to the invocation of the test() function and output this:

printMe
test

Or will it manage to keep the callback function of setTimeout aside and continue its other executions? So the output could be this, perhaps:

test
printMe

If you guessed the latter, you're right. That's where the asynchronous mechanism kicks in.

How the JavaScript Callback Queue Works (aka Task Queue)

JavaScript maintains a queue of callback functions. It is called a callback queue or task queue. A queue data structure is First-In-First-Out(FIFO). So, the callback function that first gets into the queue has the opportunity to go out first. But the question is:

• When does the JavaScript engine put it in the queue?
• When does the JavaScript engine take it out of the queue?
• Where does it go when it comes out of the queue?
• Most importantly, how do all these things relate to the asynchronous part of JavaScript?

Whoa, lots of questions! Let's figure out the answers with the help of the following image:

The above image shows the regular call stack we have seen already. There are two additional sections to track if a browser API (like setTimeout) kicks in and queues the callback function from that API.

The JavaScript engine keeps executing the functions in the call stack. As it doesn't put the callback function straight into the stack, there is no question of any code waiting for/blocking execution in the stack.

The engine creates a loop to look into the queue periodically to find what it needs to pull from there. It pulls a callback function from the queue to the call stack when the stack is empty. Now the callback function executes generally as any other function in the stack. The loop continues. This loop is famously known as the Event Loop.

So, the moral of the story is:

• When a Browser API occurs, park the callback functions in a queue.
• Keep executing code as usual in the stack.
• The event loop checks if there is a callback function in the queue.
• If so, pull the callback function from the queue to the stack and execute.
• Continue the loop.

Alright, let's see how it works with the code below:

function f1() {
    console.log('f1');
}

function f2() {
    console.log('f2');
}

function main() {
    console.log('main');

    setTimeout(f1, 0);

    f2();
}

main();

The code executes a setTimeout function with a callback function f1(). Note that we have given zero delays to it. This means that we expect the function f1() to execute immediately. Right after setTimeout, we execute another function, f2().

So, what do you think the output will be? Here it is:

main
f2
f1

But, you may think that f1 should print before f2 as we do not delay f1 to execute. But no, that's not the case. Remember the event loop mechanism we discussed above? Now, let's see it in a step-by-step flow for the above code.

Event loop - see the step-by-step execution

Here are steps written out:

1. The main() function gets inside the call stack.
2. It has a console log to print the word main. The console.log('main') executes and goes out of the stack.
3. The setTimeout browser API takes place.
4. The callback function puts it into the callback queue.
5. In the stack, execution occurs as usual, so f2() gets into the stack. The console log of f2() executes. Both go out of the stack.
6. The main() also pops out of the stack.
7. The event loop recognizes that the call stack is empty, and there is a callback function in the queue.
8. The callback function f1() then goes into the stack. Execution starts. The console log executes, and f1() also comes out of the stack.
9. At this point, nothing else is in the stack and queue to execute further.

I hope it's now clear to you how the asynchronous part of JavaScript works internally. But, that's not all. We have to look at promises.

How the JavaScript Engine Handles Promises

In JavaScript, promises are special objects that help you perform asynchronous operations.

You can create a promise using the Promise constructor. You need to pass an executor function to it. In the executor function, you define what you want to do when a promise returns successfully or when it throws an error. You can do that by calling the resolve and reject methods, respectively.

Here is an example of a promise in JavaScript:

const promise = new Promise((resolve, reject) =>
        resolve('I am a resolved promise');
);

After the promise is executed, we can handle the result using the .then() method and any errors with the .catch() method.

promise.then(result => console.log(result))

You use promises every time you use the fetch() method to get some data from a store.

The point here is that JavaScript engine doesn't use the same callback queue we have seen earlier for browser APIs. It uses another special queue called the Job Queue.

What is the Job Queue in JavaScript?

Every time a promise occurs in the code, the executor function gets into the job queue. The event loop works, as usual, to look into the queues but gives priority to the job queue items over the callback queue items when the stack is free.

The item in the callback queue is called a macro task, whereas the item in the job queue is called a micro task.

So the entire flow goes like this:

• For each loop of the event loop, one task is completed out of the callback queue.
• Once that task is complete, the event loop visits the job queue. It completes all the micro tasks in the job queue before it looks into the next thing.
• If both the queues got entries at the same point in time, the job queue gets preference over the callback queue.

The image below shows the inclusion of the job queue along with other preexisting items.

Now, let's look at an example to understand this sequence better:

function f1() {
    console.log('f1');
}

function f2() {
    console.log('f2');
}

function main() {
    console.log('main');

    setTimeout(f1, 0);

    new Promise((resolve, reject) =>
        resolve('I am a promise')
    ).then(resolve => console.log(resolve))

    f2();
}

main();

In the above code, we have a setTimeout() function as before, but we have introduced a promise right after it. Now remember all that we have learned and guess the output.

If your answer matches this, you are correct:

main
f2
I am a promise
f1

Now let's see the flow of actions:

Callback queue vs. Job queue

The flow is almost the same as above, but it is crucial to notice how the items from the job queue prioritize the items from the task queue. Also note that it doesn't even matter if the setTimeout has zero delay. It is always about the job queue that comes before the callback queue.

Alright, we have learned everything we need to understand synchronous and asynchronous execution in JavaScript.

Here is a Quiz for You!

Let's test your understanding by taking a quiz. Guess the output of the following code and apply all the knowledge we have gained so far:

function f1() {
 console.log('f1');
}

function f2() { 
    console.log('f2');
}

function f3() { 
    console.log('f3');
}

function main() {
  console.log('main');

  setTimeout(f1, 50);
  setTimeout(f3, 30);

  new Promise((resolve, reject) =>
    resolve('I am a Promise, right after f1 and f3! Really?')
  ).then(resolve => console.log(resolve));

  new Promise((resolve, reject) =>
    resolve('I am a Promise after Promise!')
  ).then(resolve => console.log(resolve));

  f2();
}

main();

Here is the expected output:

main
f2
I am a Promise, right after f1 and f3! Really?
I am a Promise after Promise!
f3
f1

Do you want more such quizzes? Head over to this repository to practice more exercises.

In case you are stuck or need any clarifications, my DM is always open on Twitter.

In Summary

To summarize:

• The JavaScript engine uses the stack data structure to keep track of currently executed functions. The stack is called the function execution stack.
• The function execution stack (aka call stack) executes the functions sequentially, line-by-line, one-by-one.
• The browser/web APIs use callback functions to complete the tasks when an asynchronous operation/delay is done. The callback function is placed in the callback queue.
• The promise executor functions are placed in the job queue.
• For each loop of the event loop, one macro task is completed out of the callback queue.
• Once that task is complete, the event loop visits the job queue. It completes all the micro-tasks in the job queue before it looks for the next thing.
• If both the queues get entries at the same point in time, the job queue gets preference over the callback queue.

Before We End...

That's all for now. I hope you've found this article insightful, and that it helps you understand JavaScript's synchronous vs asynchronous concepts better.

Let's connect. You can follow me on Twitter(@tapasadhikary), My Youtube channel, and GitHub(atapas).

As promised before, here are a few articles you may find useful,

• JavaScript Promises - Explain Like I'm Five
• JavaScript Promise Chain - The art of handling promises
• JavaScript async and await - in plain English, please
• Introducing PromiViz - visualize and learn JavaScript promise APIs

Async and await might sound complicated...but they're as easy as pizza pie once you dive in.

We all use async and await in our daily routines.

What is an async task?

An async task lets you complete other tasks while the async task is still working towards completion.

Here are some day-to-day async task examples

Example 1:

You order food at a drive-thru which starts your food request (an async task).

You pull forward in the drive-thru line (the next task), while your food is prepared.

You did not have to wait for your food to be ready before you could pull forward.

You are awaiting your food and your request is fulfilled at the pick-up window.

Example 2:

You mop the floor in your kitchen.

While you wait for your kitchen floor to dry, you vacuum the carpet in your bedroom.

The original task was to clean your kitchen floor, and the task is complete when the floor is dry.

Standing around waiting for the floor to dry is not too productive, so you vacuumed the bedroom floor while the kitchen floor dried.

This is how Javascript handles async functions, too.

Example of Async/Await – Bake a Frozen Pizza

You decide to bake a pizza in your oven, and your first step is to preheat the oven.

So you set the desired temperature and begin to preheat the oven.

While the oven is preheating, you get the frozen pizza out of the freezer, open the box, and put it on a pizza pan.

You've got time left!

Maybe grab a beverage and watch some television while you wait for the oven to beep when it is ready.

Below is some code to simulate this example:

// This async function simulates the oven response
const ovenReady = async () => {
  return new Promise(resolve => setTimeout(() => {
    resolve('Beep! Oven preheated!')
  }, 3000));
}

// Define preheatOven async function
const preheatOven = async () => {
  console.log('Preheating oven.');
  const response = await ovenReady();
  console.log(response);
}

// Define the other functions
const getFrozenPizza = () => console.log('Getting pizza.');
const openFrozenPizza = () => console.log('Opening pizza.');
const getPizzaPan = () => console.log('Getting pan.');
const placeFrozenPizzaOnPan = () => console.log('Putting pizza on pan.');
const grabABeverage = () => console.log('Grabbing a beverage.');
const watchTV = () => console.log('Watching television.');

// Now call the functions
preheatOven();
getFrozenPizza();
openFrozenPizza();
getPizzaPan();
placeFrozenPizzaOnPan();
grabABeverage();
watchTV();

// Output sequence in console:
Preheating oven.
Getting pizza.
Opening pizza.
Getting pan.
Putting pizza on pan.
Grabbing a beverage.
Watching television.
Beep! Oven preheated!

The process above is exactly what async and await is all about. 

While we `await` for the asynchronous `preheatOven` function to complete, we can perform synchronous tasks like `getFrozenPizza`, `openFrozenPizza`, `getPizzaPan`, `placeFrozenPizzaOnPan`, `grabABeverage` and even `watchTV`.

### We perform asynchronous tasks like this all the time

And that's how `async` Javascript works, too.

Notice that when we `await`a response from an `async` function, it needs to be called within another `async` function. That's what we see above when `ovenReady` is called inside of `preheatOven`.

### Two key points to remember:

1. Javascript will NOT wait for an `async` function like `preheatOven` to complete before it moves on to the tasks that follow like `getFrozenPizza` and `openFrozenPizza`. 
2. Javascript will `await` for an `async` function like `ovenReady` to complete and return data before moving on to the next task inside a parent async function. We see this when the `console.log(response)` statement does not execute until `ovenReady` has returned a response. 

## If the pizza example doesn't cut it...

I know everyday examples help some of us, but others may just prefer real code. 

Therefore, I'm going to provide a less abstract async and await JavaScript example below that requests data with the Fetch API:

## Code Example of Async/Await in JavaScript

```js
const getTheData = async () => {
    try {
    const response = await fetch('https://jsonplaceholder.typicode.com/users');
    if (!response.ok) throw Error();
    const data = await response.json();
    // do something with this data... save to db, update the DOM, etc.
    console.log(data);
    console.log('You will see this last.')
    } catch (err) {
        console.error(err);
    }
} 

getTheData();
console.log('You will see this first.');

Conclusion

I hope I have helped you understand async and await in JavaScript.

I know it can take a while to fully grasp.

Start preheating your oven for the pizza you're craving and look at some more async and await examples while you wait for the beep!

I'll leave you with a tutorial from my Youtube channel. The video gives a deeper explanation and more code examples including a discussion of callbacks, promises, thenables and the Fetch API along with async & await:

One of the hardest concepts to wrap your head around when you're first learning JavaScript is the asynchronous processing model of the language. For the majority of us, learning asynchronous programming looks pretty much like this

If your first time working with async wasn't like this, please consider yourself a genius

As hard as it is to pick up, async programming is critical to learn if you want to use JavaScript and Node.js to build web applications and servers – because JS code is asynchronous by default.

Asynchronous Programming Fundamentals

So what exactly is the asynchronous processing model, or the non-blocking I/O model (which you've likely heard of if you're a Node.js user)?

Here's a TL;DR description: in an async processing model, when your application engine interacts with external parties (like a file system or network), it doesn't wait until getting a result from those parties. Instead, it continues on to subsequent tasks and only comes back to those previous external parties once it's gotten a signal of a result.

To understand the default async processing model of Node.js, let's have a look at a hypothetical Santa's workshop. Before any work can begin, Santa will have to read each of the lovely letters from kids around the world.

He will then figure out the requested gift, translate the item name into the Elvish language, and then pass the instruction to each of our hard working elves who have different specialisations: wooden toys for Red, stuffed toys for Blue, and robotic toys for Green.

This year, due to the COVID-19 pandemic, only half Santa's elves can come to his workshop to help. Still, because he's wise, Santa decides that instead of waiting for each elf to finish preparing a gift (that is, working synchronously), he will continue translating and passing out instructions from his pile of letters.

So on and so forth...

As he is just about to read another letter, Red informs Santa that he has completed
preparing the first gift. Santa then receives the present from Red, and puts it to one side.

And then he continues translating and passing instructions from the next letter.

As he only needs to wrap a pre-made flying robot, Green can quickly finish preparation and pass the present to Santa.

After a whole day of hard and asynchronous work, Santa and the elves manage to complete all present preparation. With his improved asynchronous model of working, Santa's workshop is finished in record time despite being hard-hit by the pandemic.

So that's the basic idea of an asynchronous or non-blocking I/O processing model. Now let's see how it's done in Node.js specifically.

The Node.js Event Loop

You might have heard that Node.js is single-threaded. However, to be exact, only the event loop in Node.js, which interacts with a pool of background C++ worker threads, is single-threaded. There are four important components to the Node.js processing model:

• Event Queue: Tasks that are declared in a program, or returned from the processing thread pool via callbacks. (The equivalent of this in our Santa's workshop is the pile of letters for Santa.)
• Event Loop: The main Node.js thread that facilitates event queues and worker thread pools to carry out operations – both async and synchronous. (This is Santa. 🎅)
• Background thread pool: These threads do the actual processing of tasks, which
  might be I/O blocking (for example calling and waiting for a response from an external API). (These are the hardworking elves 🧝🧝‍♀️🧝‍♂️ from our workshop.)

You can visualize this processing model as below:

Diagram courtesy of c-sharpcorner.com

Let's look at an actual snippet of code to see these in action:

console.log("Hello");
https.get("https://httpstat.us/200", (res) => {
  console.log(`API returned status: ${res.statusCode}`);
});
console.log("from the other side");

If we execute the above piece of code, we would get this in our standard output:

Hello
from the other side
API returned status: 200

So how does the Node.js engine carry out the above snippet of code? It starts with three functions in the call stack:

"Hello" is then printed to the console with the corresponding function call removed from the stack.

The function call to https.get (that is, making a get request to the corresponding URL) is then executed and delegated to the worker thread pool with a callback attached.

The next function call to console.log gets executed, and "from the other side" is printed to the console.

Now that the network call has returned a response, the callback function call will then get queued inside the callback queue. Note that this step could happen before the immediate previous step (that is, "from the other side" getting printed), though normally that's not the case.

The callback then gets put inside our call stack:

and then we will see "API returned status: 200" in our console, like this:

By facilitating the callback queue and call stack, the event loop in Node.js efficiently executes our JavaScript code in an asynchronous way.

A synchronous history of JavaScript & Node.js async/await

Now that you have good understanding of asynchronous execution and the inner-workings of the Node.js event loop, let's dive into async/await in JavaScript. We'll look at how it's worked through time, from the original callback-driven implementation to the latest shiny async/await keywords.

Callbacks in JavaScript

The OG way of handling the asynchronous nature of JavaScript engines was through callbacks. Callbacks are basically functions which will be executed, usually, at the end of synchronous or I/O blocking operations.

A straightforward example of this pattern is the built-in setTimeout function that will wait for a certain number of milliseconds before executing the callback.

setTimeout(2000, () => {
  console.log("Hello");
});

While it's convenient to just attach callbacks to blocking operations, this pattern also introduces a couple of problems:

• Callback hell
• Inversion of control (not the good kind!)

What is callback hell?

Let's look at an example with Santa and his elves again. To prepare a present, Santa's workshop would have to carry out a few different steps (with each taking different amounts of time simulated using setTimeout):

function translateLetter(letter, callback) {
  return setTimeout(2000, () => {
    callback(letter.split("").reverse().join(""));
  });
}
function assembleToy(instruction, callback) {
  return setTimeout(3000, () => {
    const toy = instruction.split("").reverse().join("");
    if (toy.includes("wooden")) {
      return callback(`polished ${toy}`);
    } else if (toy.includes("stuffed")) {
      return callback(`colorful ${toy}`);
    } else if (toy.includes("robotic")) {
      return callback(`flying ${toy}`);
    }
    callback(toy);
  });
}
function wrapPresent(toy, callback) {
  return setTimeout(1000, () => {
    callback(`wrapped ${toy}`);
  });
}

These steps need to be carried out in a specific order:

translateLetter("wooden truck", (instruction) => {
  assembleToy(instruction, (toy) => {
    wrapPresent(toy, console.log);
  });
});
// This will produced a "wrapped polished wooden truck" as the final result

As we do things this way, adding more steps to the process would mean pushing the inner callbacks to the right and ending up in callback hell like this:

Callbacks look sequential, but at times the execution order doesn't follow what is shown on your screen. With multiple layers of nested callbacks, you can easily lose track of the big picture of the whole program flow and produce more bugs or just become slower when writing your code.

So how do you solve this problem? Simply modularise the nested callbacks into named functions and you will have a nicely left-aligned program that's easy to read.

function assembleCb(toy) {
  wrapPresent(toy, console.log);
}
function translateCb(instruction) {
  assembleToy(instruction, assembleCb);
}
translateLetter("wooden truck", translateCb);

Inversion of Control

Another problem with the callback pattern is that you don't decide how the higher-order functions will execute your callbacks. They might execute it at the end of the function, which is conventional, but they could also execute it at the start of the function or execute it multiple times.

Basically, you are at the mercy of your dependency owners, and you might never know when they will break your code.

To solve this problem, as a dependency user, there's not much you can do about it. However, if you're ever a dependency owner yourself, please always:

• Stick to the conventional callback signature with error as the first argument
• Execute a callback only once at the end of your higher-order function
• Document anything out-of-convention that is absolutely required and always aim for backward compatibility

Promises in JavaScript

Promises were created to solve these above mentioned problems with callbacks. Promises make sure that JavaScript users:

• Stick to a specific convention with their signature resolve and reject functions.
• Chain the callback functions to a well-aligned and top-down flow.

Our previous example with Santa's workshop preparing presents can be rewritten with promises like so:

function translateLetter(letter) {
  return new Promise((resolve, reject) => {
    setTimeout(2000, () => {
      resolve(letter.split("").reverse().join(""));
    });
  });
}
function assembleToy(instruction) {
  return new Promise((resolve, reject) => {
    setTimeout(3000, () => {
      const toy = instruction.split("").reverse().join("");
      if (toy.includes("wooden")) {
        return resolve(`polished ${toy}`);
      } else if (toy.includes("stuffed")) {
        return resolve(`colorful ${toy}`);
      } else if (toy.includes("robotic")) {
        return resolve(`flying ${toy}`);
      }
      resolve(toy);
    });
  });
}
function wrapPresent(toy) {
  return new Promise((resolve, reject) => {
    setTimeout(1000, () => {
      resolve(`wrapped ${toy}`);
    });
  });
}

with the steps being carried out nicely in a chain:

translateLetter("wooden truck")
  .then((instruction) => {
    return assembleToy(instruction);
  })
  .then((toy) => {
    return wrapPresent(toy);
  })
  .then(console.log);
// This would produce the exact same present: wrapped polished wooden truck

However, promises are not without problems either. Data in each eye of our chain have a different scope and only have access data passed from the immediate previous step or parent scope.

For example, our gift-wrapping step might want to use data from the translation step:

function wrapPresent(toy, instruction) {
  return Promise((resolve, reject) => {
    setTimeout(1000, () => {
      resolve(`wrapped ${toy} with instruction: "${instruction}`);
    });
  });
}

This is rather a classic "memory sharing" problem with threading. To solve this, instead of using variables in the parent's scope, we should use Promise.all and "share data by communicating, rather than communicate by sharing data".

translateLetter("wooden truck")
  .then((instruction) => {
    return Promise.all([assembleToy(instruction), instruction]);
  })
  .then((toy, instruction) => {
    return wrapPresent(toy, instruction);
  })
  .then(console.log);
// This would produce the present: wrapped polished wooden truck with instruction: "kcurt nedoow"

Async/Await in JavaScript

Last but definitely not least, the shiniest kid around the block is async/await. It is very easy to use but it also has some risks.

Async/await solves the memory sharing problems of promises by having everything under the same scope. Our previous example can be rewritten easily like so:

(async function main() {
  const instruction = await translateLetter("wooden truck");
  const toy = await assembleToy(instruction);
  const present = await wrapPresent(toy, instruction);
  console.log(present);
})();
// This would produce the present: wrapped polished wooden truck with instruction: "kcurt nedoow"

However, as much as it's easy to write asynchronous code with async/await, it's also easy to make mistakes that create performance loopholes.

Let's now localise our example Santa's workshop scenario to wrapping presents and loading them on the sleigh.

function wrapPresent(toy) {
  return Promise((resolve, reject) => {
    setTimeout(5000 * Math.random(), () => {
      resolve(`wrapped ${toy}`);
    });
  });
}
function loadPresents(presents) {
  return Promise((resolve, reject) => {
    setTimeout(5000, () => {
      let itemList = "";
      for (let i = 0; i < presents.length; i++) {
        itemList += `${i}. ${presents[i]}\n`;
      }
    });
  });
}

A common mistake you might make is carrying out the steps this way:

(async function main() {
  const presents = [];
  presents.push(await wrapPresent("wooden truck"));
  presents.push(await wrapPresent("flying robot"));
  presents.push(await wrapPresent("stuffed elephant"));
  const itemList = await loadPresents(presents);
  console.log(itemList);
})();

But does Santa need to await for each of the presents to be wrapped one by one before loading? Definitely not! The presents should be wrapped concurrently. You might make this mistake often as it's so easy to write await without thinking about the blocking nature of the keyword.

To solve this problem, we should bundle the gift wrapping steps together and execute them all at once:

(async function main() {
  const presents = await Promise.all([
    wrapPresent("wooden truck"),
    wrapPresent("flying robot"),
    wrapPresent("stuffed elephant"),
  ]);
  const itemList = await loadPresents(presents);
  console.log(itemList);
})();

Here are some recommended steps to tackle concurrency performance issue in your Node.js code:

• Identify hotspots with multiple consecutive awaits in your code
• Check if they are dependent on each other (that is one function uses data returned from another)
• Make independent function calls concurrent with Promise.all

Wrapping up (the article, not Christmas presents 😂)

Congratulations on reaching the end of this article, I tried my best to make
this post shorter, but the async topic in JavaScript is just so broad.

Here are some key takeaways:

• Modularise your JavaScript callbacks to avoid callback hell
• Stick to the convention for JS callbacks
• Share data by communicating through Promise.all when using promises
• Be careful about the performance implication of async/await code

We ❤️ JavaScript :)

Thank you for reading!

Last but not least, if you like my writings, please head over to my blog for similar commentaries and follow me on Twitter. 🎉