The code with the more restricted set of permissions must run in the Worker. That code then communicates with the rest of your app through postMessage / SharedArrayBuffer, perhaps using ComLink [2].
[1] https://deno.land/[email protected]/runtime/workers#specifying-...
Using a separate thread gets you the same GC benefits.
There have been some attempts to make it easier to use threads on the web like the excellent Comlink library: https://github.com/GoogleChromeLabs/comlink
Domenic and I have been working on a proposal[1] called Blöcks to introduce transferable functions to JavaScript.
In the meantime, I wrote Clooney[2] ontop of Comlink[3] that gives you almost that.
[1]: https://github.com/domenic/proposal-blocks
The things that have been pointed out here are similar to the feedback we’ve gotten from other browser vendors. Most crucially: We might be conflating two separate improvements here. On the one hand, there’s the ergonomics feature of async-ifying remote value and on the other introducing custom worklets that can share OS threads.
As a result, I have extracted the magic sauce from the tasklets polyfill into its own library “Comlink”[2] and I plan to write a couple of web apps using it to gather some perf data. With that data we can hopefully figure out if the ergonomics layer is worth standardizing.
Same goes for the worklets. I’ll be using good old web workers and see how big the perf impact is. With that data we can hopefully figure out if we “just” need to optimize Workers or if there’s some gains that can only be reaped by the worklet approach.
[1]: https://discourse.wicg.io/t/proposal-tasklets/2199 [2]: https://github.com/GoogleChromeLabs/comlink