What does building with GOOS=js GOARCH=wasm produce, and why does the page also need wasm_exec.js?

## What the build actually emits `GOOS=js GOARCH=wasm go build -o main.wasm ./cmd/validator` compiles your Go program — runtime, garbage collector, scheduler and all — into a single WebAssembly module. It is not an executable in the operating-system sense. A WebAssembly module is a sandboxed unit of code with its own linear memory, a list of **exports** (things the host may call) and a list of **imports** (things the host must supply before the module can even be instantiated). That import list is the whole reason a second file exists. ## Why the module cannot stand alone WebAssembly by itself has no clock, no random source, no console, no files and no access to the page. A Go program needs all of those: `time.Now`, the runtime's random seed, `fmt.Println`, and — on this target — the ability to reach JavaScript objects through the `syscall/js` package. On a normal Linux build those come from system calls. On this target they come from functions the *embedder* passes in at instantiation time. If nothing supplies them, `WebAssembly.instantiate` rejects with a link error before a single Go statement runs. ## What wasm_exec.js is `wasm_exec.js` is a small JavaScript file distributed with the Go toolchain, found under `$(go env GOROOT)/lib/wasm/`. It defines a global `Go` class. An instance of that class carries two things: `go.importObject`, the object of host functions the module imports, and `go.run(instance)`, which sets up argv and environment, calls the module's start function and returns a promise that resolves when Go's `main` returns. A minimal page therefore does three things: fetch the module, instantiate it with `go.importObject`, and call `go.run` on the resulting instance. The glue also wires the program's standard output and standard error to the browser console, buffering bytes and flushing a line at a time — which is why `fmt.Println` and Go's fatal-error output show up in devtools rather than vanishing. ## Version coupling is the trap The set of functions in `go.importObject`, and the memory layout the glue reads values out of, are private implementation details shared between the runtime and the glue. They change between Go releases. Copying `wasm_exec.js` out of a blog post, vendoring it once and forgetting it, or having CI build with a newer toolchain than the checked-in glue, all produce the same symptom: instantiation fails with a missing- or mismatched-import error, or the module starts and then misbehaves. The fix is procedural rather than clever — copy the glue as a build step, from the toolchain that just compiled the module. ## Size, and what you are shipping The whole Go runtime is in the bundle, so even a trivial program lands around a couple of megabytes uncompressed. It compresses well — serving it gzipped or brotli-compressed is not optional in production — but it is still a large asset by front-end standards, and that cost belongs to whoever owns the page's performance budget. ## What you do not get This target is a browser environment, not a small Linux. There are no OS threads: every goroutine runs on the one execution thread the module has, shared with the page's event loop. There are no sockets, so `net.Dial` does not work; the `net/http` client is instead backed by the browser's fetch API. Most of `os` is unavailable or stubbed in a browser — there is no real filesystem to open. ## The other wasm target Go has a second WebAssembly target, `GOOS=wasip1 GOARCH=wasm`, aimed at WASI hosts outside the browser. That one needs no `wasm_exec.js` at all, because the host runtime supplies the standard WASI imports itself. Browsers do not implement WASI, so `GOOS=js` remains the browser target.