3 ms·
Can that at least be a separate wasm file from some common URL so the browser can cache it?
by iforgot22 2y ago
Can that at least be a separate wasm file from some common URL so the browser can cache it?
- ahoka 2y agoBrowsers don’t do that. Caches are not shared across sites.
- iforgot22 2y agoDidn'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.
- spiffytech 2y agoNit: 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.
- iforgot22 2y agoSome of them still do, if someone is using an outdated enough browser :D for example Chrome <86 (released 2020).
- Muromec 2y agoYou 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.
- iforgot22 2y agoHm, so besides not having cross-site caching like ahoka mentioned, you can't even use some common fast CDN to host the compiled runtime.
- Muromec 2y agoIt'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.
- iforgot22 2y agoIt'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.
- dilyevsky 2y agoCan't be done until Wasm Components are widely supported by browsers and everything in wasmland moves at turtlespeed for various reasons...