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.

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!

The JavaScript runtime engine makes it a synchronous programming language where programs run sequentially. Programming languages that are not synchronous are called asynchronous programming languages, which are programming languages where programs run concurrently.

Although JavaScript is synchronous, you can perform asynchronous programming with it. In this article, you will learn about asynchronous programming in JavaScript and how to use it.

What is Asynchronous Programming?

Asynchronous programming is a technique that allows your program to run its tasks concurrently. You can compare asynchronous programming to a chef with multiple cookers, pots, and kitchen utensils. This chef will be able to cook various dishes at a time.

Asynchronous programming makes your JavaScript programs run faster, and you can perform asynchronous programming with any of these:

• Callbacks

• Promises

• Async/Await

In the upcoming sections, you will learn about these techniques and how to use them.

Callbacks

A callback is a function used as an argument in another function. Callbacks allow you to create asynchronous programs in JavaScript by passing the result of a function into another function.

function greet(name) {
    console.log(`Hi ${name}, how do you do?`);
}

function displayGreeting(callback) {
    let name = prompt("Please enter your name");
    callback(name);
};

displayGreeting(greet);

In the code above, the greet function is used to log a greeting to the console, and it needs the name of the person to be greeted.

The displayGreeting function gets the person's name and has a callback that passes the name as an argument to the greet function while calling it. Then the displayGreeting function is called with the greet function passed to it as an argument.

Callback hell

Although callbacks make it easy to control and make your program asynchronous, you'll eventually run into a problem called callback hell while using them.

This problem arises when you perform multiple asynchronous tasks with callbacks, which might result in nesting callbacks in callbacks.

Here's an example:

function greet(callback) {
    setTimeout(function() {
        console.log("Hi Musab");
        callback();
    }, 1000);
}

function introduce(callback) {
    setTimeout(function() {
        console.log("I am your academic advisor");
        callback();
    }, 1000);
}

function question(callback) {
    setTimeout(function() {
        console.log("Are you currently facing any challenge in your academics");;
        callback();
    }, 1000);
}

// callback hell
greet(function() {
    introduce(function() {
        question(function() {
            console.log("Done");
        });
    });
});

In the code above, the greet, introduce, and question functions are nested to create a callback hell, which makes error handling difficult. You should change your asynchronous programming technique from callbacks to Promise to avoid the callback hell.

Promise

Most programs consist of a producing code that performs a time-consuming task and a consuming code that needs the result of the producing code.

A Promise links the producing and the consuming code together. In the example below, the displayGreeting function is the producing code while the greet function is the consuming code.

let name;

// producing code
function displayGreeting(callback) {
    name = prompt("Please enter your name");
}

// consuming code
function greet(name) {
    console.log(`Hi ${name}, how do you do?`);
}

In the example below, the new Promise syntax creates a new Promise, which takes a function that executes the producing code. The function either resolves or rejects its task and assigns the Promise to a variable named promise.

If the producing code resolves, its result will be passed to the consuming code through the .then handler.

let name;

function displayGreeting() {
    name = prompt("Please enter your name");
}

let promise = new Promise(function(resolve, reject) {
    // the producing code
    displayGreeting();
    resolve(name)
});

function greet(result) {
    console.log(`Hi ${result}, how do you do?`);
}

promise.then(
    // the consuming code
    result => greet(result),
    error => alert(error)
);

You can convert the previous callback hell's example to a promise by returning a promise from each function and chaining the function calls together with the .then handler.

You can also use the .catch handler to catch any error thrown during the function execution.

function greet() {
    return new Promise(resolve => {
        setTimeout(function() {
            console.log("Hi Musab");
            resolve();
        }, 1000);
    });  
}

function introduce() {
    return new Promise(resolve => {
        setTimeout(function() {
            console.log("I am your academic advisor");
            resolve();
        }, 1000);
    });
}

function question() {
    return new Promise(resolve => {
        setTimeout(function() {
            console.log("Are you currently facing any challenge in your academics");;
            resolve();
        }, 1000);
    });
}

greet()
    .then(() => introduce())
    .then(() => question())
    .then(() => console.log("Done"))
    .catch(error => console.error("An error occured: ", error));

What are the States of a Promise in JavaScript?

A promise can be in any of these three states:

• Pending: This is the initial state of the promise and its state while it's still running.

• Fulfilled: This is the state of the promise when it resolves successfully.

• Rejected: This is the state of the promise when errors make it not to be resolved.

Async/Await

async/await is syntactic sugar for creating a Promise — it makes creating promises easier.

To make a function asynchronous using async/await, you have to write the async keyword before the function declaration. Then, you can write the await keyword before the producing code's execution call.

Here's an example:

let name;

function displayGreeting() {
    name = prompt("Please enter your name");
    return name;
}

function greet(result) {
    console.log(`Hi ${result}, how do you do?`);
}

async function greeting() {
    // the producing code
    let result = await displayGreeting();
    // the consuming code
    greet(result);
};

greeting();

In the example above, the producing code is the displayGreeting function, and the consuming code is the greet function. The greeting function is the Promise that connects the producing and the consuming code. It waits for the result returned from the displayGreeting function and passes that result to the greet function.

Error Handling in Async/Await

You can easily handle errors that arise when you perform asynchronous operations with async/await using the try...catch statement. The asynchronous operation executes in the try block, and you can handle errors in the catch block.

That is:

async function greeting() {
    try {
        let result = await displayGreeting();
        greet(result);
    } catch(err) {
        console.error(err)
    }
};

Conclusion

Asynchronous programming in JavaScript is used to make tasks in a program run concurrently and uses techniques such as callbacks, Promise, or async/await.

This article explains how to use these asynchronous programming techniques and how to handle errors with them.

You can check the promises and async/await section on the JavaScript.info website to learn more about asynchronous programming in JavaScript.

If you don't know or need a refresher on JavaScript promises, you can read my previous article: How JavaScript Promises Work – Tutorial for Beginners.

You'll need to understand JavaScript promises well before learning the async/await syntax.

How async/await Works

The async/await syntax is a special syntax created to help you work with promise objects. It makes your code cleaner and clearer.

When handling a Promise, you need to chain the call to the function or variable that returns a Promise using then/catch methods.

When you have many promises, you will also need lots of then method chains. For example, here's how you might retrieve data using the fetch() function:

fetch('https://jsonplaceholder.typicode.com/todos/1')
  .then(response => response.json())
  .then(json => console.log(json))
  .catch(error => console.log(error));

In the code above, the fetch() function returns a Promise, which we handle using the then() method. Inside the first then() method, we accept the response from the request and convert it into an object using the json() method.

In the second then() method, we receive the returned json data from the call to the json() method, then log that data to the console.

We also add the catch() method to handle any error that might happen when running the request.

The code is really not hard to understand, but we can make it even prettier by removing the .then() and .catch() chains, which also removes the callback functions.

The Await Keyword

The await keyword basically makes JavaScript wait until the Promise object is resolved or rejected. Instead of having to use the callback pattern inside the then() method, you can assign the fulfilled promise into a variable like this:

const response = await fetch('https://jsonplaceholder.typicode.com/todos/1');
const json = await response.json();
console.log(json)

The await keyword is placed before the call to a function or variable that returns a promise. It makes JavaScript wait for the promise object to settle before running the code in the next line.

Now if you run the code above, you might get an error like this:

SyntaxError: await is only valid in async functions and the top level bodies of modules

This error occurs because the await keyword must be used inside an asynchronous function or a module.

The Async Keyword

To create an asynchronous function, you need to add the async keyword before your function name. Take a look at line 1 in the example below:

async function runProcess() {
  const response = await fetch('https://jsonplaceholder.typicode.com/todos/1');
  const json = await response.json();
  console.log(json)
}

runProcess();

Here, we created an asynchronous function called runProcess() and put the code that uses the await keyword inside it. We can then run the asynchronous function by calling it, just like a regular function.

How to Handle Errors in Async/Await

To handle an error that might occur from the async/await syntax, you can use the try/catch block to catch any rejection from your promise.

See the example below:

async function runProcess() {
  try {
    const response = await fetch('https://jsonplaceholder.typicode.com/todos/1');
    const json = await response.json();
    console.log(json);
  } catch (error) {
    console.log(error);
  }
}

runProcess();

The try/catch block, put inside the runProcess() function, will handle the rejection that comes from the promise objects.

Now we have a complete async/await version of the standard Promise code we created earlier. Here's a comparison between the two:

Promise vs Async/Await Code Comparison

In the async/await version, the result of the promise is directly assigned to a variable. In the standard promise version, the result of the promise is passed as an argument to the .then() method.

Most developers prefer the async/await version as it looks more straightforward.

How to Use Async/Await in IIFE and Arrow Functions

An Immediately Invoked Function Expression (IIFE) is a technique used to execute a function immediately as soon as you define it.

Unlike regular functions and variables, IIFEs will be removed from the running process once they are executed.

Aside from the standard function, you can also make an asynchronous IIFE. This is useful when you need to run the asynchronous function only once:

(async function () {
  try {
    const response = await fetch('https://jsonplaceholder.typicode.com/todos/1');
    const json = await response.json();
    console.log(json);
  } catch (error) {
    console.log(error);
  }
})();

You can also use the arrow syntax when creating an asynchronous function as follows:

const runProcess = async () => {
  try {
    const response = await fetch('https://jsonplaceholder.typicode.com/todos/1');
    const json = await response.json();
    console.log(json);
  } catch (error) {
    console.log(error);
  }
};

runProcess();

Feel free to use the syntax you want in your code.

Why Use the async/await Syntax?

The async/await syntax enables you to handle promises without using .then() and .catch() method chaining, which also removes the need for nested callbacks.

This benefit is significant when you have a complex process after the promise is settled.

Going back to our example above, suppose you have a conditional statement inside the .then() method as follows:

fetch('https://jsonplaceholder.typicode.com/todos/1')
  .then(response => response.json())
  .then(json => {
    if (json.userId == 1) {
      json.completed == false;
    } else {
      json.completed == true;
    }
  })
  .catch(error => console.log(error));

Here, you can see that the callback function that accepts the json data has an if/else block inside it.

This code is hard to reason with and modify when compared to the async/await version as follows:

(async function () {
  try {
    const response = await fetch('https://jsonplaceholder.typicode.com/todos/1');
    const json = await response.json();
    if (json.userId == 1) {
      json.completed == false;
    } else {
      json.completed == true;
    }
    console.log(json);
  } catch (error) {
    console.log(error);
  }
})();

By using the async/await syntax, you reduce the need for method chaining and nested callbacks. This impact the readability of your code, especially when you have nested code like if/else and a for loop block.

Conclusion

Now you've learned how the async/await syntax works. The syntax makes working with promises much easier by removing the need for .then() and .catch() method chaining, which also removes the need for nested callbacks.

Even though the await keyword can only be used inside an async function, you can use an IIFE to invoke the async function only once.

If you enjoyed this article and want to take your JavaScript skills to the next level, I recommend you check out my new book Beginning Modern JavaScript here.

The book is designed to be easy to understand and accessible to anyone looking to learn JavaScript. It provides a step-by-step gentle guide that will help you understand how to use JavaScript to create a dynamic application.

Here's my promise: You will actually feel like you understand what you're doing with JavaScript.

Until next time!

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.

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:

• Callbacks
• Promises
• Async / Await

Here's what we'll cover in this article:

• What is Asynchronous JavaScript?
• Synchronous vs Asynchronous JavaScript
• How Callbacks Work in JavaScript
• How Promises Work in JavaScript
• How Async / Await Works in JavaScript

So let's dive in!

You can watch this tutorial on YouTube as well if you like:

What is Asynchronous JavaScript?

If you want to build projects efficiently, then this concept is for you.

The theory of async JavaScript helps you break down big complex projects into smaller tasks.

Then you can use any of these three techniques – callbacks, promises or Async/await – to run those small tasks in a way that you get the best results.

Let's dive in!🎖️

Synchronous vs Asynchronous JavaScript

What is a Synchronous System?

In a synchronous system, tasks are completed one after another.

Think of this as if you have just one hand to accomplish 10 tasks. So, you have to complete one task at a time.

Take a look at the GIF 👇 – one thing is happening at a time here:

You'll see that until the first image is loaded completely, the second image doesn't start loading.

Well, JavaScript is by default Synchronous [single threaded]. Think about it like this – one thread means one hand with which to do stuff.

What is an Asynchronous System?

In this system, tasks are completed independently.

Here, imagine that for 10 tasks, you have 10 hands. So, each hand can do each task independently and at the same time.

Take a look at the GIF 👇 – you can see that each image loads at the same time.

Again, all the images are loading at their own pace. None of them is waiting for any of the others.

To Summarize Synchronous vs Asynchronous JS:

When three images are on a marathon, in a:

• Synchronous system, three images are in the same lane. One can't overtake the other. The race is finished one by one. If image number 2 stops, the following image stops.

• Asynchronous system, the three images are in different lanes. They'll finish the race on their own pace. Nobody stops for anybody:

Synchronous and Asynchronous Code Examples

Before starting our project, let's look at some examples and clear up any doubts.

Synchronous Code Example

To test a synchronous system, write this code in JavaScript:

console.log(" I ");

console.log(" eat ");

console.log(" Ice Cream ");

Here's the result in the console: 👇

Asynchronous code example

Let's say it takes two seconds to eat some ice cream. Now, let's test out an asynchronous system. Write the below code in JavaScript.

Note: Don't worry, we'll discuss the setTimeout() function later in this article.

console.log("I");

// This will be shown after 2 seconds

setTimeout(()=>{
  console.log("eat");
},2000)

console.log("Ice Cream")

And here's the result in the console: 👇

Now that you know the difference between synchronous and async operations, let's build our ice cream shop.

How to Setup our Project

For this project you can just open Codepen.io and start coding. Or, you can do it in VS code or the editor of your choice.

Open the JavaScript section, and then open your developer console. We'll write our code and see the results in the console.

What are Callbacks in JavaScript?

When you nest a function inside another function as an argument, that's called a callback.

Here's an illustration of a callback:

An example of a callback

Don't worry, we'll see some examples of callbacks in a minute.

Why do we use callbacks?

When doing a complex task, we break that task down into smaller steps. To help us establish a relationship between these steps according to time (optional) and order, we use callbacks.

Take a look at this example:👇

Chart contains steps to make ice cream

These are the small steps you need to take to make ice cream. Also note that in this example, the order of the steps and timing are crucial. You can't just chop the fruit and serve ice cream.

At the same time, if a previous step is not completed, we can't move on to the next step.

To explain that in more detail, let's start our ice cream shop business.

But Wait...

The shop will have two parts:

• The storeroom will have all the ingredients [Our Backend]
• We'll produce ice cream in our kitchen [The frontend]

Let's store our data

Now, we're gonna store our ingredients inside an object. Let's start!

You can store the ingredients inside objects like this: 👇

let stocks = {
    Fruits : ["strawberry", "grapes", "banana", "apple"]
 }

Our other ingredients are here: 👇

You can store these other ingredients in JavaScript objects like this: 👇

let stocks = {
    Fruits : ["strawberry", "grapes", "banana", "apple"],
    liquid : ["water", "ice"],
    holder : ["cone", "cup", "stick"],
    toppings : ["chocolate", "peanuts"],
 };

The entire business depends on what a customer orders. Once we have an order, we start production and then we serve ice cream. So, we'll create two functions ->

• order
• production

This is how it all works: 👇

Get order from customer, fetch ingredients, start production, then serve.

Let's make our functions. We'll use arrow functions here:

let order = () =>{};

let production = () =>{};

Now, let's establish a relationship between these two functions using a callback, like this: 👇

let order = (call_production) =>{

  call_production();
};

let production = () =>{};

Let's do a small test

We'll use the console.log() function to conduct tests to clear up any doubts we might have regarding how we established the relationship between the two functions.

let order = (call_production) =>{

console.log("Order placed. Please call production")

// function 👇 is being called 
  call_production();
};

let production = () =>{

console.log("Production has started")

};

To run the test, we'll call the order function. And we'll add the second function named production as its argument.

// name 👇 of our second function
order(production);

Here's the result in our console 👇

Take a break

So far so good – take a break!

Clear out the console.log

Keep this code and remove everything [don't delete our stocks variable]. On our first function, pass another argument so that we can receive the order [Fruit name]:

// Function 1

let order = (fruit_name, call_production) =>{

  call_production();
};

// Function 2

let production = () =>{};


// Trigger 👇

order("", production);

Here are our steps, and the time each step will take to execute.

Chart contains steps to make ice cream

In this chart, you can see that step 1 is to place the order, which takes 2 seconds. Then step 2 is cut the fruit (2 seconds), step 3 is add water and ice (1 second), step 4 is to start the machine (1 second), step 5 is to select the container (2 seconds), step 6 is to select the toppings (3 seconds) and step 7, the final step, is to serve the ice cream which takes 2 seconds.

To establish the timing, the function setTimeout() is excellent as it is also uses a callback by taking a function as an argument.

Syntax of a setTimeout() function

Now, let's select our fruit and use this function:

// 1st Function

let order = (fruit_name, call_production) =>{

  setTimeout(function(){

    console.log(`${stocks.Fruits[fruit_name]} was selected`)

// Order placed. Call production to start
   call_production();
  },2000)
};

// 2nd Function

let production = () =>{
  // blank for now
};

// Trigger 👇
order(0, production);

And here's the result in the console: 👇

Note that the result is displayed after 2 seconds.

If you're wondering how we picked strawberry from our stock variable, here's the code with the format 👇

Don't delete anything. Now we'll start writing our production function with the following code.👇 We'll use arrow functions:

let production = () =>{

  setTimeout(()=>{
    console.log("production has started")
  },0000)

};

And here's the result 👇

We'll nest another setTimeout function in our existing setTimeout function to chop the fruit. Like this: 👇

let production = () =>{

  setTimeout(()=>{
    console.log("production has started")


    setTimeout(()=>{
      console.log("The fruit has been chopped")
    },2000)


  },0000)
};

And here's the result 👇

If you remember, here are our steps:

Chart contains steps to make ice cream

Let's complete our ice cream production by nesting a function inside another function – this is also known as a callback, remember?

let production = () =>{

  setTimeout(()=>{
    console.log("production has started")
    setTimeout(()=>{
      console.log("The fruit has been chopped")
      setTimeout(()=>{
        console.log(`${stocks.liquid[0]} and ${stocks.liquid[1]} Added`)
        setTimeout(()=>{
          console.log("start the machine")
          setTimeout(()=>{
            console.log(`Ice cream placed on ${stocks.holder[1]}`)
            setTimeout(()=>{
              console.log(`${stocks.toppings[0]} as toppings`)
              setTimeout(()=>{
                console.log("serve Ice cream")
              },2000)
            },3000)
          },2000)
        },1000)
      },1000)
    },2000)
  },0000)

};

And here's the result in the console 👇

Feeling confused?

This is called callback hell. It looks something like this (remember that code just above?): 👇

Illustration of Callback hell

What's the solution to this?

How to Use Promises to Escape Callback Hell

Promises were invented to solve the problem of callback hell and to better handle our tasks.

Take a break

But first, take a break!

This is how a promise looks:

illustration of a promise format

Let's dissect promises together.

An illustration of the life of a promise

As the above charts show, a promise has three states:

• Pending: This is the initial stage. Nothing happens here. Think of it like this, your customer is taking their time giving you an order. But they haven't ordered anything yet.
• Resolved: This means that your customer has received their food and is happy.
• Rejected: This means that your customer didn't receive their order and left the restaurant.

Let's adopt promises to our ice cream production case study.

But wait...

We need to understand four more things first ->

• Relationship between time and work
• Promise chaining
• Error handling
• The .finally handler

Let's start our ice cream shop and understand each of these concepts one by one by taking baby steps.

Relationship between time and work

If you remember, these are our steps and the time each takes to make ice cream"

Chart contains steps to make ice cream

For this to happen, let's create a variable in JavaScript: 👇

let is_shop_open = true;

Now create a function named order and pass two arguments named time, work:

let order = ( time, work ) =>{

  }

Now, we're gonna make a promise to our customer, "We will serve you ice-cream" Like this ->

let order = ( time, work ) =>{

  return new Promise( ( resolve, reject )=>{ } )

  }

Our promise has 2 parts:

• Resolved [ ice cream delivered ]
• Rejected [ customer didn't get ice cream ]

let order = ( time, work ) => {

  return new Promise( ( resolve, reject )=>{

    if( is_shop_open ){

      resolve( )

    }

    else{

      reject( console.log("Our shop is closed") )

    }

  })
}

Let's add the time and work factors inside our promise using a setTimeout() function inside our if statement. Follow me 👇

Note: In real life, you can avoid the time factor as well. This is completely dependent on the nature of your work.

let order = ( time, work ) => {

  return new Promise( ( resolve, reject )=>{

    if( is_shop_open ){

      setTimeout(()=>{

       // work is 👇 getting done here
        resolve( work() )

// Setting 👇 time here for 1 work
       }, time)

    }

    else{
      reject( console.log("Our shop is closed") )
    }

  })
}

Now, we're gonna use our newly created function to start ice-cream production.

// Set 👇 time here
order( 2000, ()=>console.log(`${stocks.Fruits[0]} was selected`))
//    pass a ☝️ function here to start working

The result 👇 after 2 seconds looks like this:

Good job!

Promise chaining

In this method, we defining what we need to do when the first task is complete using the .then handler. It looks something like this 👇

Illustration of promise chaining using .then handler

The .then handler returns a promise when our original promise is resolved.

Here's an Example:

Let me make it simpler: it's similar to giving instructions to someone. You tell someone to " First do this, then do that, then this other thing, then.., then.., then..." and so on.

• The first task is our original promise.
• The rest of the tasks return our promise once one small bit of work is completed

Let's implement this on our project. At the bottom of your code write the following lines. 👇

Note: don't forget to write the return word inside your .then handler. Otherwise, it won't work properly. If you're curious, try removing the return once we finish the steps:

order(2000,()=>console.log(`${stocks.Fruits[0]} was selected`))

.then(()=>{
  return order(0000,()=>console.log('production has started'))
})

And here's the result: 👇

Using the same system, let's finish our project:👇

// step 1
order(2000,()=>console.log(`${stocks.Fruits[0]} was selected`))

// step 2
.then(()=>{
  return order(0000,()=>console.log('production has started'))
})

// step 3
.then(()=>{
  return order(2000, ()=>console.log("Fruit has been chopped"))
})

// step 4
.then(()=>{
  return order(1000, ()=>console.log(`${stocks.liquid[0]} and ${stocks.liquid[1]} added`))
})

// step 5
.then(()=>{
  return order(1000, ()=>console.log("start the machine"))
})

// step 6
.then(()=>{
  return order(2000, ()=>console.log(`ice cream placed on ${stocks.holder[1]}`))
})

// step 7
.then(()=>{
  return order(3000, ()=>console.log(`${stocks.toppings[0]} as toppings`))
})

// Step 8
.then(()=>{
  return order(2000, ()=>console.log("Serve Ice Cream"))
})

Here's the result: 👇

Error handling

We need a way to handle errors when something goes wrong. But first, we need to understand the promise cycle:

An illustration of the life of a promise

To catch our errors, let's change our variable to false.

let is_shop_open = false;

Which means our shop is closed. We're not selling ice cream to our customers anymore.

To handle this, we use the .catch handler. Just like .then, it also returns a promise, but only when our original promise is rejected.

A small reminder here:

• .then works when a promise is resolved
• .catch works when a promise is rejected

Go down to the very bottom and write the following code:👇

Just remember that there should be nothing between your previous .then handler and the .catch handler.

.catch(()=>{
  console.log("Customer left")
})

Here's the result:👇

A couple things to note about this code:

• The 1st message is coming from the reject() part of our promise
• The 2nd message is coming from the .catch handler

How to use the .finally() handler

There's something called the finally handler which works regardless of whether our promise was resolved or rejected.

For example: whether we serve no customers or 100 customers, our shop will close at the end of the day

If you're curious to test this, come at very bottom and write this code: 👇

.finally(()=>{
  console.log("end of day")
})

The result:👇

Everyone, please welcome Async / Await~

How Does Async / Await Work in JavaScript?

This is supposed to be the better way to write promises and it helps us keep our code simple and clean.

All you have to do is write the word async before any regular function and it becomes a promise.

But first, take a break

Let's have a look:👇

Promises vs Async/Await in JavaScript

Before async/await, to make a promise we wrote this:

function order(){
   return new Promise( (resolve, reject) =>{

    // Write code here
   } )
}

Now using async/await, we write one like this:

//👇 the magical keyword
 async function order() {
    // Write code here
 }

But wait......

You need to understand ->

• How to use the try and catch keywords
• How to use the await keyword

How to use the Try and Catch keywords

We use the try keyword to run our code while we use catch to catch our errors. It's the same concept we saw when we looked at promises.

Let's see a comparison. We'll see a small demo of the format, then we'll start coding.

Promises in JS -> resolve or reject

We used resolve and reject in promises like this:

function kitchen(){

  return new Promise ((resolve, reject)=>{
    if(true){
       resolve("promise is fulfilled")
    }

    else{
        reject("error caught here")
    }
  })
}

kitchen()  // run the code
.then()    // next step
.then()    // next step
.catch()   // error caught here
.finally() // end of the promise [optional]

Async / Await in JS -> try, catch

When we're using async/await, we use this format:

//👇 Magical keyword
async function kitchen(){

   try{
// Let's create a fake problem      
      await abc;
   }

   catch(error){
      console.log("abc does not exist", error)
   }

   finally{
      console.log("Runs code anyways")
   }
}

kitchen()  // run the code

Don't panic, we'll discuss the await keyword next.

Now hopefully you understand the difference between promises and Async / Await.

How to Use JavaScript's Await Keyword

The keyword await makes JavaScript wait until a promise settles and returns its result.

How to use the await keyword in JavaScript

Let's go back to our ice cream shop. We don't know which topping a customer might prefer, chocolate or peanuts. So we need to stop our machine and go and ask our customer what they'd like on their ice cream.

Notice here that only our kitchen is stopped, but our staff outside the kitchen will still do things like:

• doing the dishes
• cleaning the tables
• taking orders, and so on.

An Await Keyword Code Example

Let's create a small promise to ask which topping to use. The process takes three seconds.

function toppings_choice (){
  return new Promise((resolve,reject)=>{
    setTimeout(()=>{

      resolve( console.log("which topping would you love?") )

    },3000)
  })
}

Now, let's create our kitchen function with the async keyword first.

async function kitchen(){

  console.log("A")
  console.log("B")
  console.log("C")

  await toppings_choice()

  console.log("D")
  console.log("E")

}

// Trigger the function

kitchen();

Let's add other tasks below the kitchen() call.

console.log("doing the dishes")
console.log("cleaning the tables")
console.log("taking orders")

And here's the result:

We are literally going outside our kitchen to ask our customer, "what is your topping choice?" In the mean time, other things still get done.

Once, we get their topping choice, we enter the kitchen and finish the job.

Small note

When using Async/ Await, you can also use the .then, .catch, and .finally handlers as well which are a core part of promises.

Let's open our Ice cream shop again

We're gonna create two functions ->

• kitchen: to make ice cream
• time: to assign the amount of time each small task will take.

Let's start! First, create the time function:

let is_shop_open = true;

function time(ms) {

   return new Promise( (resolve, reject) => {

      if(is_shop_open){
         setTimeout(resolve,ms);
      }

      else{
         reject(console.log("Shop is closed"))
      }
    });
}

Now, let's create our kitchen:

async function kitchen(){
   try{

     // instruction here
   }

   catch(error){
    // error management here
   }
}

// Trigger
kitchen();

Let's give small instructions and test if our kitchen function is working or not:

async function kitchen(){
   try{

// time taken to perform this 1 task
     await time(2000)
     console.log(`${stocks.Fruits[0]} was selected`)
   }

   catch(error){
     console.log("Customer left", error)
   }

   finally{
      console.log("Day ended, shop closed")
    }
}

// Trigger
kitchen();

The result looks like this when the shop is open: 👇

The result looks like this when the shop is closed: 👇

So far so good.

Let's complete our project.

Here's the list of our tasks again: 👇

Chart contains steps to make ice cream

First, open our shop

let is_shop_open = true;

Now write the steps inside our kitchen() function: 👇

async function kitchen(){
    try{
    await time(2000)
    console.log(`${stocks.Fruits[0]} was selected`)

    await time(0000)
    console.log("production has started")

    await time(2000)
    console.log("fruit has been chopped")

    await time(1000)
    console.log(`${stocks.liquid[0]} and ${stocks.liquid[1]} added`)

    await time(1000)
    console.log("start the machine")

    await time(2000)
    console.log(`ice cream placed on ${stocks.holder[1]}`)

    await time(3000)
    console.log(`${stocks.toppings[0]} as toppings`)

    await time(2000)
    console.log("Serve Ice Cream")
    }

    catch(error){
     console.log("customer left")
    }
}

And here's the result: 👇

Conclusion

Congratulations for reading until the end! In this article you've learned:

• The difference between synchronous and asynchronous systems
• Mechanisms of asynchronous JavaScript using 3 techniques (callbacks, promises, and Async/ Await)

Here's your medal for reading until the end. ❤️

Suggestions and criticisms are highly appreciated ❤️

YouTube / Joy Shaheb

LinkedIn / JoyShaheb

Twitter / JoyShaheb

Instagram / JoyShaheb

Credits

• Collection of all the images used
• Unicorns, kitty avatar
• tabby cat, Astrologist Woman, girl-holding-flower
• Character emotions

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

On the web, many things tend to be time-consuming – if you query an API, it can take a while to receive a response. Therefore, asynchronous programming is an essential skill for developers.

When working with asynchronous operations in JavaScript, we often hear the term Promise. But it can be tricky to understand how they work and how to use them.

Unlike many traditional coding tutorials, in this tutorial we'll learn by doing. We'll complete four tasks by the end of the article:

• Task 1: Promise basics explained using my birthday
• Task 2: Build a guessing game
• Task 3: Fetch country info from an API
• Task 4: Fetch a country's neighboring countries

If you want to follow along, be sure to download the resources here: https://bit.ly/3m4bjWI

Task 1: Promise basics explained using my birthday

My friend Kayo promises to make a cake for my birthday in two weeks.

If everything goes well and Kayo doesn't get sick, we'll have a certain number of cakes. (Cakes are a countable in this tutorial 😆). Otherwise, if Kayo gets sick, we'll have no cakes.

Either way, we're still going to have a party.

For this first task, we'll translate this story into code. First, let's create a function that returns a Promise:

const onMyBirthday = (isKayoSick) => {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      if (!isKayoSick) {
        resolve(2);
      } else {
        reject(new Error("I am sad"));
      }
    }, 2000);
  });
};

In JavaScript, we can create a new Promise with new Promise(), which takes in a function as an argument: (resolve, reject) => {}.

In this function, resolve and reject are callback functions that are provided by default in JavaScript.

Let's take a closer look at the code above.

When we run the onMyBirthday function, after 2000ms:

• If Kayo is not sick, then we run resolve with 2 as the argument
• If Kayo is sick then we run reject with new Error("I am sad") as the argument. Even though you can pass anything to reject as an argument, it's recommended to pass it an Error object.

Now, because onMyBirthday() returns a Promise, we have access to the then, catch, and finally methods.

And we also have access to the arguments that were passed into resolve and reject earlier within then and catch.

Let's take a closer look at the code.

If Kayo is not sick:

onMyBirthday(false)
  .then((result) => {
    console.log(`I have ${result} cakes`); // In the console: I have 2 cakes  
  })
  .catch((error) => {
    console.log(error); // Does not run
  })
  .finally(() => {
    console.log("Party"); // Shows in the console no matter what: Party
  });

If Kayo is sick:

onMyBirthday(true)
  .then((result) => {
    console.log(`I have ${result} cakes`); // does not run 
  })
  .catch((error) => {
    console.log(error); // in console: Error: I am sad
  })
  .finally(() => {
    console.log("Party"); // Shows in the console no matter what: Party
  });

Alright, so by now, I hope you get the basic idea of Promise. Let's move onto task 2.

Task 2: Build a guessing game

The requirements:

• User story: A user can enter a number
• User story: The system picks a random number from 1 to 6
• User story: If the user's number is equal to a random number, give the user 2 points
• User story: If the user's number is different than the random number by 1,
  give the user 1 point. Otherwise, give the user 0 points
• User story: The user can play the game as long as they want to

For the first 4 user stories, let's create an enterNumber function and return a Promise:

const enterNumber = () => {
  return new Promise((resolve, reject) => {
    // Let's start from here
  });
};

The first thing we need to do is to ask for a number from user and pick a random number between 1 and 6:

const enterNumber = () => {
  return new Promise((resolve, reject) => {
    const userNumber = Number(window.prompt("Enter a number (1 - 6):")); // Ask the user to enter a number
    const randomNumber = Math.floor(Math.random() * 6 + 1); // Pick a random number between 1 and 6
  });
};

Now, userNumber can enter a value, that is not a number. If so, let's call the reject function with an error:

const enterNumber = () => {
  return new Promise((resolve, reject) => {
    const userNumber = Number(window.prompt("Enter a number (1 - 6):")); // Ask user to enter a number
    const randomNumber = Math.floor(Math.random() * 6 + 1); // Pick a random number between 1 and 6

    if (isNaN(userNumber)) {
      reject(new Error("Wrong Input Type")); // If the user enters a value that is not a number, run reject with an error
    }
  });
};

The next thing we want to do is to check if the userNumber is equal to randomNumber, if so, we want give user 2 points and we can run the resolve function passing an object { points: 2, randomNumber }. Notice here that we also want to know the randomNumber when the Promise is resolved

If the userNumber is different than randomNumber by one, then we give the user 1 point. Otherwise, we give the user 0 points:

return new Promise((resolve, reject) => {
  const userNumber = Number(window.prompt("Enter a number (1 - 6):")); // Ask the user to enter a number
  const randomNumber = Math.floor(Math.random() * 6 + 1); // Pick a random number between 1 and 6

  if (isNaN(userNumber)) {
    reject(new Error("Wrong Input Type")); // If the user enters a value that is not a number, run reject with an error
  }

  if (userNumber === randomNumber) {
    // If the user's number matches the random number, return 2 points
    resolve({
      points: 2,
      randomNumber,
    });
  } else if (
    userNumber === randomNumber - 1 ||
    userNumber === randomNumber + 1
  ) {
    // If the user's number is different than the random number by 1, return 1 point
    resolve({
      points: 1,
      randomNumber,
    });
  } else {
    // Else return 0 points
    resolve({
      points: 0,
      randomNumber,
    });
  }
});

Alright, let's also create another function to ask if the user wants to continue the game:

const continueGame = () => {
  return new Promise((resolve) => {
    if (window.confirm("Do you want to continue?")) { // Ask if the user want to continue the game with a confirm modal
      resolve(true);
    } else {
      resolve(false);
    }
  });
};

Notice here that we create a Promise, but it does not use the reject callback. This is totally fine.

Now let's create a function to handle the guess:

const handleGuess = () => {
  enterNumber() // This returns a Promise
    .then((result) => {
      alert(`Dice: ${result.randomNumber}: you got ${result.points} points`); // When resolve is run, we get the points and the random number 

      // Let's ask the user if they want to continue the game
      continueGame().then((result) => {
        if (result) {
          handleGuess(); // If yes, we run handleGuess again
        } else {
          alert("Game ends"); // If no, we show an alert
        }
      });
    })
    .catch((error) => alert(error));
};

handleGuess(); // Run handleGuess function

Here when we call handleGuess, enterNumber() now returns a Promise:

• If the Promise is resolved, we call the then method and show an alert message. We also ask if the user wants to continue.
• If the Promise is rejected, we show an alert message with the error.

As you can see, the code is quite difficult to read.

Let's refactor the handleGuess function a bit using the async/await syntax:

const handleGuess = async () => {
  try {
    const result = await enterNumber(); // Instead of the then method, we can get the result directly by just putting await before the promise

    alert(`Dice: ${result.randomNumber}: you got ${result.points} points`);

    const isContinuing = await continueGame();

    if (isContinuing) {
      handleGuess();
    } else {
      alert("Game ends");
    }
  } catch (error) { // Instead of catch method, we can use the try, catch syntax
    alert(error);
  }
};

You can see that we created an async function by putting async before the brackets. Then in the async function:

• Instead of the then method, we can get the results directly just by putting await before the promise
• Instead of the catch method, we can use the try, catch syntax

Here's all the code for this task again for your reference:

const enterNumber = () => {
  return new Promise((resolve, reject) => {
    const userNumber = Number(window.prompt("Enter a number (1 - 6):")); // Ask the user to enter a number
    const randomNumber = Math.floor(Math.random() * 6 + 1); // Pick a random number between 1 and 6

    if (isNaN(userNumber)) {
      reject(new Error("Wrong Input Type")); // If the user enters a value that is not a number, run reject with an error
    }

    if (userNumber === randomNumber) { // If the user's number matches the random number, return 2 points
      resolve({
        points: 2,
        randomNumber,
      });
    } else if (
      userNumber === randomNumber - 1 ||
      userNumber === randomNumber + 1
    ) { // If the user's number is different than the random number by 1, return 1 point
      resolve({
        points: 1,
        randomNumber,
      });
    } else { // Else return 0 points
      resolve({
        points: 0,
        randomNumber,
      });
    }
  });
};

const continueGame = () => {
  return new Promise((resolve) => {
    if (window.confirm("Do you want to continue?")) { // Ask if the user want to continue the game with a confirm modal
      resolve(true);
    } else {
      resolve(false);
    }
  });
};

const handleGuess = async () => {
  try {
    const result = await enterNumber(); // Instead of the then method, we can get the result directly by just putting await before the promise

    alert(`Dice: ${result.randomNumber}: you got ${result.points} points`);

    const isContinuing = await continueGame();

    if (isContinuing) {
      handleGuess();
    } else {
      alert("Game ends");
    }
  } catch (error) { // Instead of catch method, we can use the try, catch syntax
    alert(error);
  }
};

handleGuess(); // Run handleGuess function

Alright, we are done with the second task. Let's move on to the third one.

Task 3: Fetch country info from an API

You'll see Promises used a lot when fetching data from an API.

If you open https://restcountries.eu/rest/v2/alpha/col in a new browser, you will see the country data in JSON format.

By using the Fetch API, we can fetch the data by:

const fetchData = async () => {
  const res = await fetch("https://restcountries.eu/rest/v2/alpha/col"); // fetch() returns a promise, so we need to wait for it

  const country = await res.json(); // res is now only an HTTP response, so we need to call res.json()

  console.log(country); // Columbia's data will be logged to the dev console
};

fetchData();

Now that we have the country data we want, let's move onto the last task.

Task 4: Fetch a country's neighboring countries

If you open task 4, you will see that we have a fetchCountry function, that fetches the data from the endpoint: https://restcountries.eu/rest/v2/alpha/${alpha3Code} where alpha3code is the code of the country.

You also see that it will catch any error that might happen when getting the data.

// Task 4: get the neigher countries of Columbia

const fetchCountry = async (alpha3Code) => {
  try {
    const res = await fetch(
      `https://restcountries.eu/rest/v2/alpha/${alpha3Code}`
    );

    const data = await res.json();

    return data;
  } catch (error) {
    console.log(error);
  }
};

Let's create a fetchCountryAndNeighbors function and fetch Columbia's information by passing col as the alpha3code.

const fetchCountryAndNeighbors = async () => {
  const columbia = await fetchCountry("col");

  console.log(columbia);
};

fetchCountryAndNeighbors();

Now, if you look in your console, you can see an object look like this:

In the object, there is a border property which is a list of alpha3codes for Columbia's neighboring countries.

Now if we try to get the neighboring countries by:

  const neighbors = 
    columbia.borders.map((border) => fetchCountry(border));

Then, neighbors will be an array of Promise objects.

When working with an array of promises, we need to use Promise.all:

const fetchCountryAndNeigbors = async () => {
  const columbia = await fetchCountry("col");

  const neighbors = await Promise.all(
    columbia.borders.map((border) => fetchCountry(border))
  );

  console.log(neighbors);
};

fetchCountryAndNeigbors();

In the console, we should be able to see list of country objects.

Here's all the code for task 4 again for your reference:

const fetchCountry = async (alpha3Code) => {
  try {
    const res = await fetch(
      `https://restcountries.eu/rest/v2/alpha/${alpha3Code}`
    );

    const data = await res.json();

    return data;
  } catch (error) {
    console.log(error);
  }
};

const fetchCountryAndNeigbors = async () => {
  const columbia = await fetchCountry("col");

  const neighbors = await Promise.all(
    columbia.borders.map((border) => fetchCountry(border))
  );

  console.log(neighbors);
};

fetchCountryAndNeigbors();

Conclusion

After completing these 4 tasks, you can see that Promise is useful when it comes to asynchronous actions or things that are not happening at the same time.

You can see this in practice in one of my tutorials, where we build an application from scratch with React and Next.js:

__ 🐣 About me __

• I am the founder of DevChallenges
• Subscribe to my YouTube Channel
• Follow me on Twitter
• Join Discord

When does an asynchronous function finish? And why is this such a hard question to answer?

Well it turns out that understanding asynchronous functions requires a great deal of knowledge about how JavaScript works fundamentally.

Let's go explore this concept, and learn a lot about JavaScript in the process.

Are you ready? Let's go.

What is asynchronous code?

By design, JavaScript is a synchronous programming language. This means that when code is executed, JavaScript starts at the top of the file and runs through code line by line, until it is done.

The result of this design decision is that only one thing can happen at any one time.

You can think of this as if you were juggling six small balls. While you are juggling, your hands are occupied and can't handle anything else.

It's the same with JavaScript: once the code is running, it has its hands full with that code. We call this this kind of synchronous code blocking. Because it's effectively blocking other code from running.

Let's circle back to the juggling example. What would happen if you wanted to add another ball? Instead of six balls, you wanted to juggle seven balls. That's might be a problem.

You don't want to stop juggling, because it's just so much fun. But you can't go and get another ball either, because that would mean you'd have to stop.

The solution? Delegate the work to a friend or family member. They aren't juggling, so they can go and get the ball for you, then toss it into your juggling at a time when your hand is free and you are ready to add another ball mid-juggle.

This is what asynchronous code is. JavaScript is delegating the work to something else, then going about it's own business. Then when it's ready, it will receive the results back from the work.

Who is doing the other work?

Alright, so we know that JavaScript is synchronous and lazy. It doesn't want to do all of the work itself, so it farms it out to something else.

But who is this mysterious entity that works for JavaScript? And how does it get hired to work for JavaScript?

Well, let's take a look at an example of asynchronous code.

const logName = () => {
   console.log("Han")
}

setTimeout(logName, 0)

console.log("Hi there")

Running this code results in the following output in the console:

// in console
Hi there
Han

Alright. What is going on?

It turns out that the way we farm out work in JavaScript is to use environment-specific functions and APIs. And this is a source of great confusion in JavaScript.

JavaScript always runs in an environment.

Often, that environment is the browser. But it can also be on the server with NodeJS. But what on earth is the difference?

The difference – and this is important – is that the browser and the server (NodeJS), functionality-wise, are not equivalent. They are often similar, but they are not the same.

Let's illustrate this with an example. Let's say JavaScript is the protagonist of an epic fantasy book. Just an ordinary farm kid.

Now let's say that this farm kid found two suits of special armor that gave them powers beyond their own.

When they used the browser suit of armor, they gained access to a certain set of capabilities.

When they used the server suit of armor they gained access to another set of capabilities.

These suits have some overlap, because the creators of these suits had the same needs in certain places, but not in others.

This is what an environment is. A place where code is run, where there exist tools that are built on top of the existing JavaScript language. They are not a part of the language, but the line is often blurred because we use these tools every day when we write code.

setTimeout, fetch, and DOM are all examples of Web APIs. (You can see the full list of Web APIs here.) They are tools that are built into the browser, and that are made available to us when our code is run.

And because we always run JavaScript in an environment, it seems like these are part of the language. But they are not.

So if you've ever wondered why you can use fetch in JavaScript when you run it in the browser (but need to install a package when you run it in NodeJS), this is why. Someone thought fetch was a good idea, and built it as a tool for the NodeJS environment.

Confusing? Yes!

But now we can finally understand what takes on the work from JavaScript, and how it gets hired.

It turns out that it is the environment that takes on the work, and the way to get the environment to do that work, is to use functionality that belongs to the environment. For example fetch or setTimeout in the browser environment.

What happens to the work?

Great. So the environment takes on the work. Then what?

At some point you need to get the results back. But let's think about how this would work.

Let's go back to the juggling example from the beginning. Imagine you asked for a new ball, and a friend just started throwing the ball at you when you weren't ready.

That would be a disaster. Maybe you could get lucky and catch it and get it into your routine effectively. But theres a large chance that it may cause you to drop all of your balls and crash your routine. Wouldn't it be better if you gave strict instructions on when to receive the ball?

As it turns out, there are strict rules surrounding when JavaScript can receive delegated work.

Those rules are governed by the event loop and involve the microtask and macrotask queue. Yes, I know. It's a lot. But bear with me.

Alright. So when we delegate asynchronous code to the browser, the browser takes and runs the code and takes on that workload. But there may be multiple tasks that are given to the browser, so we need to make sure that we can prioritise these tasks.

This is where the microtask queue and the macrotask queue come in play. The browser will take the work, do it, then place the result in one of the two queues based on the type of work it receives.

Promises, for example, are placed in the microtask queue and have a higher priority.

Events and setTimeout are examples of work that is put in the macrotask queue, and have a lower priority.

Now once the work is done, and is placed in one of the two queues, the event loop will run back and forth and check whether or not JavaScript is ready to receive the results.

Only when JavaScript is done running all its synchronous code, and is good and ready, will the event loop start picking from the queues and handing the functions back to JavaScript to run.

So let's take a look at an example:

setTimeout(() => console.log("hello"), 0) 

fetch("https://someapi/data").then(response => response.json())
                             .then(data => console.log(data))

console.log("What soup?")

What will the order be here?

1. Firstly, setTimeout is delegated to the browser, which does the work and puts the resulting function in the macrotask queue.
2. Secondly fetch is delegated to the browser, which takes the work. It retrieves the data from the endpoint and puts the resulting functions in the microtask queue.
3. Javascript logs out "What soup"?
4. The event loop checks whether or not JavaScript is ready to receive the results from the queued work.
5. When the console.log is done, JavaScript is ready. The event loop picks queued functions from the microtask queue, which has a higher priority, and gives them back to JavaScript to execute.
6. After the microtask queue is empty, the setTimeout callback is taken out of the macrotask queue and given back to JavaScript to execute.

In console:
// What soup?
// the data from the api
// hello

Promises

Now you should have a good deal of knowledge about how asynchronous code is handled by JavaScript and the browser environment. So let's talk about promises.

A promise is a JavaScript construct that represents a future unknown value. Conceptually, a promise is just JavaScript promising to return a value. It could be the result from an API call, or it could be an error object from a failed network request. You're guaranteed to get something.

const promise = new Promise((resolve, reject) => {
    // Make a network request
   if (response.status === 200) {
      resolve(response.body)
   } else {
      const error = { ... }
      reject(error)
   }
})

promise.then(res => {
    console.log(res)
}).catch(err => {
    console.log(err)
})

A promise can have the following states:

• fulfilled - action successfully completed
• rejected - action failed
• pending - neither action has been completed
• settled - has been fulfilled or rejected

A promise receives a resolve and a reject function that can be called to trigger one of these states.

One of the big selling points of promises is that we can chain functions that we want to happen on success (resolve) or failure (reject):

• To register a function to run on success we use .then
• To register a function to run on failure we use .catch

// Fetch returns a promise
fetch("https://swapi.dev/api/people/1")
    .then((res) => console.log("This function is run when the request succeeds", res)
    .catch(err => console.log("This function is run when the request fails", err)

// Chaining multiple functions
 fetch("https://swapi.dev/api/people/1")
    .then((res) => doSomethingWithResult(res))
    .then((finalResult) => console.log(finalResult))
    .catch((err => doSomethingWithErr(err))

Perfect. Now let's take a closer look at what this looks like under the hood, using fetch as an example:

const fetch = (url, options) => {
  // simplified
  return new Promise((resolve, reject) => {

  const xhr = new XMLHttpRequest()
  // ... make request
  xhr.onload = () => {
    const options = {
        status: xhr.status,
        statusText: xhr.statusText
        ...
    }

    resolve(new Response(xhr.response, options))
  }

  xhr.onerror = () => {
    reject(new TypeError("Request failed"))
  }
}

 fetch("https://swapi.dev/api/people/1")
   // Register handleResponse to run when promise resolves
    .then(handleResponse)
  .catch(handleError)

 // conceptually, the promise looks like this now:
 // { status: "pending", onsuccess: [handleResponse], onfailure: [handleError] }

 const handleResponse = (response) => {
  // handleResponse will automatically receive the response, ¨
  // because the promise resolves with a value and automatically injects into the function
   console.log(response)
 }

  const handleError = (response) => {
  // handleError will automatically receive the error, ¨
  // because the promise resolves with a value and automatically injects into the function
   console.log(response)
 }

// the promise will either resolve or reject causing it to run all of the registered functions in the respective arrays
// injecting the value. Let's inspect the happy path:

// 1. XHR event listener fires
// 2. If the request was successfull, the onload event listener triggers
// 3. The onload fires the resolve(VALUE) function with given value
// 4. Resolve triggers and schedules the functions registered with .then

So we can use promises to do asynchronous work, and to be sure that we can handle any result from those promises. That is the value proposition. If you want to know more about promises you can read more about them here and here.

When we use promises, we chain our functions onto the promise to handle the different scenarios.

This works, but we still need to handle our logic inside callbacks (nested functions) once we get our results back. What if we could use promises but write synchronous looking code? It turns out we can.

Async/Await

Async/Await is a way of writing promises that allows us to write asynchronous code in a synchronous way. Let's have a look.

const getData = async () => {
    const response = await fetch("https://jsonplaceholder.typicode.com/todos/1")
    const data = await response.json()

    console.log(data)
}

getData()

Nothing has changed under the hood here. We are still using promises to fetch data, but now it looks synchronous, and we no longer have .then and .catch blocks.

Async / Await is actually just syntactic sugar providing a way to create code that is easier to reason about, without changing the underlying dynamic.

Let's take a look at how it works.

Async/Await lets us use generators to pause the execution of a function. When we are using async / await we are not blocking because the function is yielding the control back over to the main program.

Then when the promise resolves we are using the generator to yield control back to the asynchronous function with the value from the resolved promise.

You can read more here for a great overview of generators and asynchronous code.

In effect, we can now write asynchronous code that looks like synchronous code. Which means that it is easier to reason about, and we can use synchronous tools for error handling such as try / catch:

const getData = async () => {
    try {
        const response = await fetch("https://jsonplaceholder.typicode.com/todos/1")
        const data = await response.json()
        console.log(data)
    } catch (err) {
       console.log(err)
    }

}

getData()

Alright. So how do we use it? In order to use async / await we need to prepend the function with async. This does not make it an asynchronous function, it merely allows us to use await inside of it.

Failing to provide the async keyword will result in a syntax error when trying to use await inside a regular function.

const getData = async () => {
    console.log("We can use await in this function")
}

Because of this, we can not use async / await on top level code. But async and await are still just syntactic sugar over promises. So we can handle top level cases with promise chaining:

async function getData() {
  let response = await fetch('http://apiurl.com');
}

// getData is a promise
getData().then(res => console.log(res)).catch(err => console.log(err);

This exposes another interesting fact about async / await. When defining a function as async, it will always return a promise.

Using async / await can seem like magic at first. But like any magic, it's just sufficiently advanced technology that has evolved over the years. Hopefully now you have a solid grasp of the fundamentals, and can use async / await with confidence.

Conclusion

If you made it here, congrats. You just added a key piece of knowledge about JavaScript and how it works with its environments to your toolbox.

This is definitely a confusing subject, and the lines are not always clear. But now you hopefully have a grasp on how JavaScript works with asynchronous code in the browser, and a stronger grasp over both promises and async / await.

If you enjoyed this article, you might also enjoy my youtube channel. I currently have a web fundamentals series going where I go through HTTP, building web servers from scratch and more.

There's also a series going on building an entire app with React, if that is your jam. And I plan to add much more content here in the future going in depth on JavaScript topics.

And if you want to say hi or chat about web development, you could always reach out to me on twitter at @foseberg. Thanks for reading!