2021-04-14
1135
#vanilla javascript
Paul Cowan
42536
Apr 14, 2021 ⋅ 4 min read

JavaScript generators: The superior async/await

Paul Cowan Contract software developer.

Recent posts:

the replay nov 19

The Replay (11/19/25): React 19.2: The async shift is finally here

Discover what’s new in The Replay, LogRocket’s newsletter for dev and engineering leaders, in the November 19th issue.

Matt MacCormack
Nov 19, 2025 ⋅ 33 sec read

React 19.2: The async shift is finally here

Jack Herrington writes about how React 19.2 rebuilds async handling from the ground up with use(), , useTransition(), and now View Transitions.

Jack Herrington
Nov 19, 2025 ⋅ 5 min read

Offline-first frontend apps in 2025: IndexedDB and SQLite in the browser and beyond

The web has always had an uneasy relationship with connectivity. Most applications are designed as if the network will be […]

Alexander Godwin
Nov 18, 2025 ⋅ 11 min read
Real-Time AI In Next.js How To Stream Responses With The Vercel AI SDK

Real-time AI in Next.js: How to stream responses with the Vercel AI SDK

Streaming AI responses is one of the easiest ways to improve UX. Here’s how to implement it in a Next.js app using the Vercel AI SDK—typing effect, reasoning, and all.

Elijah Asaolu
Nov 17, 2025 ⋅ 9 min read
View all posts

6 Replies to "JavaScript generators: The superior async/await"

  1. I think you are misunderstanding the differences between promises and yield. Just about all of your examples are simpler with async versions and the error handling is far easier than with yield. Especially when nested. You also seem to be confusing asynchronously I/O with yielding during iteration… They are vastly different use cases and the last thing you want to do for asynchronous I/O is yield back to the caller.

  2. I’m not sure if author knows what he is writing about. About sample about stopping websocket is not good idea cause what will happen when we stop execution of generator – > websocket got an issue – > we resumes generator – > error occurs, i think writing this code in async await manner will be much more simple in case of error handling

  3. 1. I think you are misunderstanding the differences between promises and yield. Just about all of your examples are simpler with async versions and the error handling is far easier than with yield.
    2. Especially when nested.
    3. You also seem to be confusing asynchronously I/O with yielding during iteration…
    4. They are vastly different use cases and the last thing you want to do for asynchronous I/O is yield back to the caller.

    This is 1 opinion followed by 3 assertions. Do you have evidence for any of these claims?

  4. That last example doesn’t really show any benefit over the async await experience. Also I’m wary of anything in javascript that uses “process” semantics. Under the hood JS engines handle a single function call at a time so suggesting otherwise seems disingenuous. Unless the idea is that multiprocess patterns are just inherently more readable? That’s even more dubious.

    Here’s an async/await equivalent to your flakeyconnection example. It’s written fairly quickly but it should work. Whether or not one is more confusing than the other is a matter of debate, but a point in favor of the async await example is that it introduces no new libraries or concepts other than the standard:

    const slep = (ms: number) => {
    return new Promise((resolve) => setTimeout(resolve, ms));
    }
    const someApiCall = async () => {
    throw new Error(“oops”);
    }
    const flakey= async () => {
    let tries = 5;
    let result = undefined;
    while (tries > 0) {
    try {
    const r = await someApiCall();
    } catch (e) {
    }
    tries–;
    await slep(1000);
    }

    if(!result) {
    // do something, probably throw error
    }

    return result;
    }

    Another benefit of the async/await example is that it’s exactly the same pattern as if you had a flakey function that was not async.

  5. Ah actually my previous comment was in error. Your example was for a timeout, not for a number of re-tries.

    In that case the promise version would be slightly altered:

    const timeout = (secs:number) => {
    return new Promise((resolve, reject) => {
    setTimeout(() => reject(“timeout exceeded”), secs);
    });
    }

    const sleep = (secs:number) => {
    return new Promise((resolve, reject) => {
    setTimeout(resolve, secs);
    });
    }
    const someApiCall = async () => {
    throw new Error(“oops”);
    }
    const flakey = async () => {
    while (true) {
    try {
    return await someApiCall();
    } catch (e) {
    }
    await sleep(1000);
    }
    }

    const main = () => {
    try {
    const result = Promise.race([flakey(), timeout(500)]);
    } catch(e) {
    // time out exceeded.
    }
    }

    Still more readable than the generator version. Especially the Promise.race(…) makes it immediately obvious that this code is dealing with “timeouts”. Whereas in the generator version, we have to read through the whole setup to understand fully what’s going on. Which, honestly is why I missed the point of your example in the first place. Granted, that is just me being the lowest common denominator 😀

Leave a Reply

Hey there, want to help make our blog better?

Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.

Sign up now