"nice" threading support is not there but you can have threaded wasm code in any evergreen browser since a more then a year as far as I'm aware Basically the

"nice" threading support is not there but you can have threaded wasm code in any evergreen browser since a more then a year as far as I'm aware Basically the trick is that you use multiple web-workers with the same WAS program and the same shared buffer. Then you also add some JS glue code to coordinate which thread is the main thread and which threads you use as thread pool (e.g. in rust/wasm with rayon you can set it up as worker pool). Now there are some drawbacks (last time when I used it, might have gotten better): - threads are started/managed from outside (so don't expect any kind of "spawn" function to work, generally spawning new threads is non-trivial and so is (properly) cleaning up old threads, through if you need a fixed worker pool it's all fine) - there where some limitations wrt. threading/synchronization which made certain usages of concurrency rather slow (through many where fine) - no "synchronized" operations mustn't be called from WASM code called by the main JS thread. This means in most situations you need to pass data to web workers and then to WASM (instead of e.g. passing it to WASM and then using in wasm a mpmc-channel to pass it to the worker pool). There are some optimizations around passing pointers as numbers to/from the web-workers but it's limited and not nice. Or at least wasn't ~a year ago. - bugs in Safari leading to strange crashed for code running in all other browsers nicely under unclear and non-debuggable circumstances (probably fixed, I hope) Anyway all in all using rust->wasm with rayon and a thread pool was already surprisingly viable ~1 year ago.