Coroutines in JavaScript for web components (lorenzofox.dev)

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

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.

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.

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 use generators to handle performant asynchronous bitstream parsing. Using promises is far too slow: https://github.com/astronautlabs/bitstream

The coolest thing (IMO) compared to react is the ability to await inside a component.

I love this for some reason. However, I wonder if it would end up being more complicated than React in practice. I generally prefer pedantic/stricter usage guidelines/conventions.

I started experimenting with this recently. Neither my knowledge nor the maturity is at a level where I would use it for production work but there are definitely some promising aspects to this. I am preparing a talk about it.

The most significant unknown for me is how state management (like Redux etc.) would work in a larger app. I can think of many solutions but I can't figure out whether the tradeoffs then result in a net gain or loss.

I think this is my first time seeing techniques like “for ({} of this) {…}”, very interesting.

This is a common idiom when working with generators, since iteration is controlled on the consuming side. Consider e.g. a trivial generator that counts up from one:

  function * makeSequence() {
    let i = 1;
    while (true) yield i++;
  }

This function returns an iterator:

  const ints = makeSequence();

And now the caller is control of iteration, not the callee:

  function sumTo(cutoff) {
    const ints = makeSequence();
    let sum = 0;
    for (let i = 0; i < cutoff; i++) {
      sum += ints.next().value;
    }
    return sum;
  }

In this case there is no risk of an infinite loop.

More brave would be:

  while (0.1 + 0.2 !== 0.3)

Things like that tend to be relatively easy to unit test as long as you have sane (read: few) exit conditions.

Not the author, but I believe the idea they want to illustrate is that you can't get into accidental render loops caused by the component itself

That's... a really cool idea

Sounds cool but in practice downloading a wasm bundle is bandwidth heavy and rendering to the dom in a browser is different than rendering to a string.

Have you heard of Qwik framework? Not really you’re suggesting implementation wise, but they have their own idea for resumable rendering.

Sadly React disallows this pattern even though this interface is in the DOM spec

I'm not entirely sure what this adds in this case, though. For example, in the code you've written, as far as I can tell there's no advantage compared to defining the function as a closure variable and using it directly, rather than defining it as an attribute on `this` and passing the `this` object around.

In addition, with the `handleEvent` approach, you need to handle all events within a single function. But it's fairly easy to create multiple functions within a single function scope and pass them to different event handlers, thus avoiding the need for the large (and potentially error-prone) switch statement if you end up needing to handle lots of events.

Have you found cases where `handleEvent` works better than just defining local variables within a function and just using those? It seems to me that you wouldn't even need arrow functions to take advantage of the natural power of closures in this context.

  function Counter(buttonElement) {
     this.clicked = 0;
     buttonElement.addEventlistener("click", this, false);
  }
  Counter.prototype = {
     reset: function() { this.clicked = 0; },
     log: function() { concole.log("I was clicked " + this.clicked + " times."); },
     handleEvent: function(event) { this.clicked++; this.log(); }
  };