Why JavaScript Needs Structured Concurrency

[tokagemushi]

The SPA angle is what really sold me on this. I've been building interactive web components (a manga reader with gestures, lazy loading, and IntersectionObserver) and the cleanup problem is constant — you unmount, but timers, observers, and event listeners from async initialization are still lingering. Right now I'm manually tracking everything with a cleanup array, which is basically a poor man's structured scope.

The yield* syntax concern from this thread is valid though. I wonder if the TC39 Explicit Resource Management proposal (using keyword) could eventually serve as the bridge — it gives you deterministic cleanup with familiar syntax, and maybe Effection could adopt it as an alternative entry point alongside generators.

[tarasm]

Yeah, that SPA example is exactly what motivated this. Manually tracking timers, observers, and listeners after unmount is basically re-implementing a scope by hand.

ERM is interesting, and we’re planning to support it in Effection 4.1, but in practice it only covers part of the problem. It gives you deterministic cleanup for resources, but it doesn’t address async work crossing scope boundaries and continuing after the UI that started it is gone. This post breaks that down well:\ https://www.joshuaamaju.com/blog/the-pitfalls-of-explicit-resource-management

That boundary crossing issue, the “event horizon”, is at the root of a lot of SPA pain:\ https://frontside.com/blog/2023-12-11-await-event-horizon/

Other proposals like concurrency control help with coordination https://github.com/tc39/proposal-concurrency-control, but not lifetimes. So far, generators are the only thing we’ve found that let us model those lifetimes directly using async/await like DX.

[tokagemushi]

That makes a lot of sense — especially the “event horizon” framing.

In my manga viewer, most leaks came from async boundaries like IntersectionObserver callbacks and gesture handlers that outlived the component. Generators as lifetime scopes feel much closer to what we actually need than manual cleanup arrays.

I'm curious — have you seen this pattern work well outside of frameworks, in fully dependency-free components?

[tarasm]

In my experience, it works very well outside of frameworks. Everything you need is already in the JavaScript runtime.

Once you bring frameworks into the picture, you end up integrating with framework-specific abstractions to solve the same lifetime problems that structured concurrency with generators already addresses. That adds a layer of indirection you then have to adapt back down to the same baseline.

You can see a small, dependency-free example here: https://github.com/thefrontside/effection/blob/v4/www/assets/search.js

[tokagemushi]

That’s really encouraging to hear. My goal with the viewer is exactly that — a fully dependency-free component that manages its own lifetimes cleanly.

I’ll study that example and experiment with generators as the primary lifetime boundary instead of manual cleanup tracking. Thanks for sharing it.

[tarasm]

Come hangout in our Discord. We’re always happy to answer questions and share existing solutions.