Hacker News Reader

Comment by apatheticonion | Hacker News Reader

Fair, you're right that typically you'd have a dedicated UI thread with workers handling business logic.

The difference with Rust and Go is they have better synchronization capabilities - where JavaScript largely forces you to clone data between threads.

So while you may still be messaging worker threads in Rust/Go - threads share memory which is fast and you have access to things like atomics and mutexes.

We can use Rust in the browser today with WASM and it's super cool - but without something like WASI, extensive thunking through JavaScript is required, plus there are issues with threading.

I hope that one day we can initialize a wasm module via a script tag with the browser offering a wasi interface

`<script src="module.wasm" type="application/wasi">`

And that browsers allow for threading without the restrictive security headers we have today

View on HN

There is a proposal to add threading to WASM itself

https://github.com/WebAssembly/threads/blob/main/proposals/t...

But that’s not going to help when accessing the DOM.

Oh nice! That will be helpful. I guess WASI doesn't help with DOM access either - that's more about file access and such?

Is there a proposal(s) covering DOM access?

I remember interface types were a thing a few years back. If you have access to a dom object (I assume by pointer?) and it is removed/GC'd - would the wasm module have a null pointer?

> JavaScript largely forces you to clone data between threads.

Isn't that what SharedArrayBuffer is for (avoiding)?

Indeed. And there’s a whole Atomics namespace in the standard library for thread safety while using it.

Again, there’s very few actual uses for wasm. The main one is when you have a preexisting library in a different language, other than that you don’t gain any real functionality from using it.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

SharedArrayBuffers are helpful for simple data types but because they are a simple fixed size array of bytes, you cannot share things like objects, class instances, arrays, etc and you need to manually extend the SAB by creating multiple SAB "pages" and manually glue them together. Ultimately it's not useful for most practical use-cases.

In the past I have used a SharedArrayBuffer to store a custom Graph implementation sent between threads. I stored the adjacency list in the SAB with the rest of the data being stored as a plain object and cloned/sent via postMessage between threads.

This worked but is extremely janky, required an unsafe custom data structure, manual/unsafe memory page management, was difficult to read/review and the performance was lacklustre because half of the data structure was plain JS objects that needed to be serialized and cloned anyway.

Simply, JavaScript sucks for multithreading and it would be great to have the ability to write high performance, multithreaded, complex web applications in a language designed with parallelism in mind - like Rust or Go.

While wasm _today_ cannot offer that (at least not practically) - there is certainly a use case for replacing JavaScript in that context and I hope that it does.

JS will still be useful for basic applications that just need a little scripting

SAB solves the problem of having a small number of dedicated workers that efficiently handle specific well constrained data processing tasks.

I must question whether the problem of random sites wanting to spin up a whole ton of cores that consume arbitrary amounts of compute and memory really needs to be solved.

Reply on news.ycombinator.com