There's no CGO involved when compiling to Wasm. The sometimes slow performance is due to the hoops the compiled code has to jump through to support the Go runtime and goroutine preemption on a single thread.

I understand there's no CGo specifically, but I'm wondering if the Go runtime when running under WASM still has to manage switching out the goroutine stacks for "WASM stacks" when it's calling out through the WASM VM.

Edit edit: from this comment it sounds like it is, as you say, just the general overhead of managing goroutine stacks. I wonder if TinyGo is more performant.

[1] https://news.ycombinator.com/item?id=37501552

Tinygo runtime don’t have g or m threads that’s why it’s Cgo is zero cost

Exports are something we'd like to work on but it turns out it's pretty complicated to reconcile the Go runtime with the WebAssembly environment, especially when there's only a single thread. We'll get to exports as soon as we can but it may require Wasm threads to be stable first.

Just curious what state is it (thread support) in now? I saw wasmtime already supporting some pthread style threads so assumed proposal has already been accepted but it’s super hard to actually figure out what state anything is in with wasm…

The answer is: it's complicated. Which is most of the time the answer in the WASI world.

For this case it's complicated because some runtime supports https://github.com/WebAssembly/threads which mostly contains things like the spec for atomic but not the actual "threads" specs and then some runtimes (i.e wasmtime) also supports https://github.com/WebAssembly/wasi-threads which is one version of the threads. But a new proposal came into play https://github.com/abrown/thread-spawn so ... it's complicated.

Yes, "it's complicated" is very diplomatic way of putting it after like 5+ years...

Don't know about the server side, but I've been using threads on the browser for ~2 months, I didn't hit any bug specific to it yet. I use it both with Rust (wasmbindgen with async/await) and C (Emscripten with pthread support). HTTPS with some headers is required for `SharedArrayBuffer`.

I still build a single-threaded binary for Firefox, and fallback to it if `SharedArrayBuffer` is `undefined` or if the `WebAssembly.Memory` constructor fails (some iOS devices might throw when `shared` is `true` due to a bug).

I would like to second that last statement. If anyone knows a good place to keep up with it all I'd appreciate it

Threads are Phase 3

https://github.com/WebAssembly/proposals

You can also check out:

https://webassembly.org/roadmap/

And for Go, the proposal project on Github has many interesting conversations from the devs.

And as a reminder to anyone interested in using Go WASM, it’s experimental and does not come with the same compatibility promise as Go itself:

https://github.com/golang/go/wiki/WebAssembly

Yes it's been in phase 3 for what like 2-3 years at this point (judging by when it landed in browsers)? No eta and no next steps. The tp says they are waiting until "it's stable" so I'm assuming phase 4. It qualifies browser support and "at least one toolchain" criteria[0] (zig) and seems like all the other conditions too except maybe "CG consensus" whatever that means, so for all I know it could take anywhere between tomorrow and in a few years from now...

[0] https://github.com/WebAssembly/meetings/blob/main/process/ph...

FWIW the WASI support is 99% a community contribution, so unfortunately it's not much of an indicator of Google's commitment.

The type conversion will improve in new releases. FYI recent TinyGo releases supports go:wasmimport too. The desire is definitely to allow users to use either or at least easily migrate. Thank you for trying it out!

Accompanying tech blog post: https://www.kwoodhouse.co.uk/tech/trail-tracker

Mind sharing some details? I've been working on this myself and I don't have much JS ecosystem experience. I found the same issue around using tailwindcss as a postcss plugin (it basically tripled my build time), so would love to hear alternative solutions.

I'm the author of this blog post and one of the maintainers of the Improbable grpc-web implementation.

I don't explicitly mention it in the post, but no browser has support for fetch request streaming yet, so true bidirectionality would not be possible even if you had control over the headers. This will come eventually, and then grpc-web will have proper bi-di streaming support. It is doubtful whether it will actually have access to raw HTTP/2 frames which would be required for the gRPC HTTP/2 protocol.

Hi, I'm the author of this blog post _and_ the author of this repository - so happy to hear you're finding it useful! I agree that the grpc-gateway is very useful still, but for greenfield projects I think it would be useful to consider the grpc-web on its own merits. I see the grpc-gateway as a way to integrate gRPC into existing environments.