How do you decide whether to ship a Go library to the browser as wasm when another team owns the bundle budget?

## Why this is a decision and not a technique Compiling Go to WebAssembly for a browser is easy. Deciding to make it someone else's problem is not. The engineer proposing it usually owns the Go library and gains code reuse; the engineer who has to accept it owns the page's load performance and pays in bytes, build complexity and a new failure mode. Both are right about their own concerns, which is why the decision needs a shared frame rather than a preference. ## Name the cost precisely A Go WebAssembly module carries the entire runtime, scheduler and garbage collector, so even a thin library lands in the low megabytes uncompressed. It compresses well, and the number that matters is the compressed transfer size on the specific page that will load it, measured, not estimated. Around it sit costs people forget: the toolchain glue script that must be copied from the same Go release and kept in step; a Go toolchain added to the front-end build and CI; a boundary where every string and buffer is copied in both directions; a single execution thread shared with the page, so heavy work needs a Web Worker or it janks the UI; and stack traces that now come from a runtime the front-end team cannot debug. ## Name the benefit precisely There is one benefit that reliably justifies the cost: **divergence would be a defect**. If the browser accepts a document that the server later rejects, or vice versa, that is a user-visible bug that a second implementation makes inevitable over time. Validators, parsers, tariff and pricing rules, and canonicalisation logic all sit in that category. Anything where the client copy is a convenience — a hint, a preview, a nicety — does not: a small hand-written approximation is cheaper and its drift is harmless. So the first question to ask is not “can we” but “what breaks when the two implementations disagree, and how would we find out?” ## Price the alternatives before arguing for this one Three options usually deserve comparison. Run the logic **server-side** behind an endpoint: zero bundle cost, a round trip per check, and it fails when offline — often perfectly acceptable for a form that submits anyway. **Extract the rules into data** — a schema, a table, a small expression language — that both a Go and a JavaScript interpreter read: this keeps one source of truth without shipping a runtime, and is the option most often overlooked. Or **ship the wasm module**. Presenting all three, with the measured numbers, is what makes the conversation a decision rather than a negotiation. ## Get the target right If it ships to a page, it is the browser WebAssembly target with the toolchain's JavaScript glue. The WASI target is for hosts outside the browser — a plugin surface inside another process, an edge runtime — and choosing it for a page is a category error, since browsers do not implement WASI. Both targets are single-threaded, so neither buys parallelism. ## Own the operational contract Saying yes creates obligations that outlive the decision, and they should be written down before anyone merges: - **Who rebuilds** the module when the Go library changes, and how the front end pins a version. A wasm artefact that silently lags the server's rules recreates the divergence you shipped it to prevent — the worst possible outcome, because it looks like it is working. - **What the page does when the module fails to load or instantiate.** The honest answer is fall back to the server check; the dishonest one is skip validation and hope. - **Where the work runs**, main thread or worker, decided by whether the operation can exceed a frame budget. - **Whether the exported surface is asynchronous by default.** It should be, because a callback that blocks inside a call from JavaScript deadlocks the page, and retrofitting that convention across a published surface is expensive. ## Who decides The platform owner proposes; the owner of the page's performance budget can overrule, and that is legitimate. Your job as the proposer is to make the trade legible — the measured compressed cost, the concrete defect class it removes, the alternatives you priced, and the fallback when it does not load. If the answer is still no, the reusable fallback is the rules-as-data option, which usually survives the objection that killed the module. ## The revisit trigger Record what would change the answer: the library growing rules too intricate to keep in sync by hand, a measured divergence incident, or the page acquiring an offline requirement. Decisions like this age, and an explicit trigger is what stops the team relitigating it from memory every year.