Hacker News Reader

Comment by HumanOstrich | Hacker News Reader

Although I tend to mostly use async/await these days, I find the other JavaScript asynchronous primitives interesting. Generator functions, iterables, and async versions of the two.

The author shows a plausible way to put these primitives together to create coroutines powering rendering and lifecycles for web components. And although I'm pretty familiar with the syntax involved, I still learned some new ways to put it together from this article.

Also the author's previous intro article to coroutines in JavaScript might be helpful for learning the basic syntax and patterns: https://lorenzofox.dev/posts/coroutine/

View on HN

I’ve tried to get into Streams at one point, for their promise of efficient processing of large (infinite) streams of data. Great for stuff like kafka / event streams.

There is a lot of very nice functionality in Node around it - pipe functions and the like, and it can work, but in the end I’ve settled on just using async iterators.

It’s just so easy and understandable to go

   for await (const item of my AsyncIterator) { … }

And for people who don’t grasp in detail how it all works, the abstraction is very easy to use.

I'm the same camp. I use async/await because they exist and it's usually a good idea to use similar approaches to other devs, but I question why we even needed async/await in the first place. It's a big deal to add syntax to a whole language, and a small one to add a function to a library. We have

  const foo = async function() {
    const user = await fetchUser()

But if they'd just made a Promise.coroutine, you could equivalently do this without needing to change the language:

  const foo = co(function* () {
    const user = yield fetchUser()

There's some unpopular cases like async iterables or async generators, but for the most part we could've done the same thing without extending the language. I remember the v1 of koa that had yield everywhere and people thought it was confusing af. Then they released with await and suddenly it made sense to people.

Interesting take. One could argue that by adding async functions on top of classic and generator ones we now have three different colors for the functions instead of just tw.

Async await is a syntactic sugar for functional continuations. These are “free” for C stacks, in a sense. Coroutines are not, because you have to yield and resume across C calls sometimes. The common argument for async await is that you avoid making system interfaces resumable. Another argument is that await explicitly marks yield-across points and there’s no sudden yield through an incomplete or potentially unsynchronized state.

I use generators to handle performant asynchronous bitstream parsing. Using promises is far too slow: https://github.com/astronautlabs/bitstream

What are some use cases of using generators to do coroutines?

I honestly can't think of an example that couldn't be handled in a stateful way, by using objects/class instances instead of closures.

Even iteration can be handled by implementing [Symbol.iterator] on the instance.

The one place I found a use for them is to syncify async functions in some rare cases where it's needed, as the API would only work with other non-sync functions.

Although it doesn't really matter for much I've found closures to run faster than accessing class properties and found classes to use less memory than closures.

Handling user inputs. Each time the generator yields you wait for a user input, and when you receive it you next() the generator with the input. It’s less verbose than using a bunch of methods, or the closest alternative I saw which is a switch/case on the index of the current operation. By using generators you just reuse the standard structures of the language.

I love how he used an EventTarget to simply the code.

Reply on news.ycombinator.com