There is a big project for TypeScript called Effect (https://effect.website/). I think their motto should be “we will sacrifice everything to not employ BEAM”. But first let me tell you about some interesting aspects of Effect.
The library implements interrupts, fiber-scoped resource acquisition-release, internal synchronization primitives (like critical sections and message passing between threads). If you are thinking “hey, are they implementing OS inside JS” — yeah, that’s pretty much it.
That’s effect-ively a whole virtual machine with instructions represented by JS closures. By building hierarchies of closures via function calls (monad transformers) you build the fiber code in runtime, and then execute the code (i.e. call the closure that will call next closure), possible execute the code multiple times, possibly interrupting the execution mid-way.

The official website itself confirms that Effect is an overkill for simple apps. So they are targeting complex apps with many concurrent and diverse fibers. As you might know, there is a default limit of ~6 concurrent HTTP requests in browsers. So Effect is definitely a backend-only library.
Now why would you employ a single-threaded VM runtime to run your “highly concurrency and performant” nested VM with cooperative multitasking? That’s a rhetoric question. And it’s not even fast on V8, because closure churn trashes JIT optimizations (closures escaping to non-local scope = unoptimizable code in V8).

It feels like a classic routine of creating a screwdriver capable of efficient nail hammering and wall painting. “Why use screwdriver to paint walls?” — coz we have lots of screwdriver experts with 10 years of experience, but we need to paint a wall too. Don’t get me wrong, it can be fun, but if you are doing a commercial product then your “best practices” and “expertise” are doing a negative impact to your project, you lose so much more by going through the horrible debugging experience of Effect (common problem of many async runtimes). Effect authors promised better debugging tools, but we are still waiting.

Right now just pick Elixir or Gleam, and you will get native support of error handling, retries, timeouts, tracing — all composable, debuggable, and observable, with JIT optimizations, and you will save lives of many innocent closures that would not be fed to a lambda machine. And learning Effect library can be as hard as learning Elixir. Seriously, you will not be rendering React.js components asynchronously with Effect, there is exactly zero reasons to employ a wrong tool (JS) for the job.