Hacker News Reader

Comment by iforgot22 | Hacker News Reader

Can that at least be a separate wasm file from some common URL so the browser can cache it?

You can't have dymanic linking of two C-like libraries compiled to wasm, because you would not be able to pass pointers around. Basically everything you compile to wasm becomes static binary which needs some bitfiddling to interact with.

Hm, so besides not having cross-site caching like ahoka mentioned, you can't even use some common fast CDN to host the compiled runtime.

It's more of a go problem than the wasm problem. Don't bundle such a big runtime and pass memory pointers around and you can have nice things.

Something beam-hosted with zero pointer sharing between nodes and smaller runtime maps to wasm much better.

It's also unfortunate for a lot of heavy JS libs out there that they can't be cached locally anymore, but security is important.

One WASM-related case I've actually encountered in the wild is Unity web. Similar problem as Golang, the runtime is heavy.

Browsers don’t do that. Caches are not shared across sites.

Didn't expect that, but not very surprised. So short of the browser giving the Go runtime some special treatment, this sounds like a no-go.

Nit: they don't do that anymore, because cross-origin caches cause privacy problems. But they used to, and this news is still percolating through the industry.

Some of them still do, if someone is using an outdated enough browser :D for example Chrome <86 (released 2020).

Can't be done until Wasm Components are widely supported by browsers and everything in wasmland moves at turtlespeed for various reasons...

Reply on news.ycombinator.com