gofetch-wasm : JavaScript Deserved a Real HTTP Client

#gofetch#wasm#go#javascript

For more than a decade, JavaScript developers have relied on the same pattern for networking:

Start with fetch.
Wrap it.
Add timeouts.
Add retries.
Fix errors.
Repeat — in every project.

Despite how central HTTP is to modern applications, JavaScript never standardized a full-featured, correct-by-default HTTP client. Instead, each runtime exposed low-level primitives, and the ecosystem filled the gap with libraries and wrappers — all slightly different, all subtly inconsistent.

That gap is what led to gofetch-wasm.

The problem with today’s status quo

fetch was designed to be minimal. That’s not a flaw — but it is a limitation.

Out of the box, it provides:

no default timeouts
no retries
weak error semantics
runtime-dependent behavior

Libraries like Axios improve ergonomics, but they still rely on runtime-specific networking APIs. As a result, the same request can behave differently in the browser, Node.js, edge runtimes, or tests.

For simple apps, this is fine.
For tooling, SDKs, CLIs, and cross-runtime code, it becomes a real problem.

One behavior, everywhere

The core idea behind gofetch-wasm is simple:

Networking behavior should not depend on where your JavaScript runs.

Instead of wrapping existing JS APIs, gofetch-wasm embeds a single HTTP engine into WebAssembly and exposes it to JavaScript and TypeScript.

That engine is Go’s net/http.

Go solved HTTP networking early:

sane defaults
structured errors
cancellation via contexts
predictable request lifecycles

By compiling this stack to WebAssembly, gofetch-wasm allows the same HTTP logic to run in:

browsers
Node.js
edge runtimes
future WASM-capable environments

This is not a fetch wrapper

This distinction matters.

gofetch-wasm does not delegate requests to:

fetch
XMLHttpRequest
Node’s http module

Request logic, lifecycle management, and error handling live inside the WebAssembly module, while actual network I/O is performed by the host runtime.JavaScript becomes the API layer — not the networking layer.

This is what enables more consistent behavior across environments.

Correctness over convenience

gofetch-wasm is not designed to replace fetch in every app.

It’s built for cases where:

behavior consistency matters
networking bugs are costly
code runs in more than one runtime
infrastructure should be boring and predictable

The goal is not to add more features, but to reduce surprises.

Is it production-ready?

The underlying HTTP engine is based on Go’s well-established net/http package.
That said, gofetch-wasm itself is a new project and is still evolving.

It’s best suited today for early adopters, tooling, and teams that value correctness and are comfortable adopting emerging infrastructure.

Stability, transparency, and long-term maintainability are the priorities.

Trade-offs and constraints

Running an HTTP client inside WebAssembly introduces additional bundle size and runtime overhead compared to native fetch.

For browser-based, performance-critical, or consumer-facing applications, this overhead may not be acceptable.

gofetch-wasm intentionally trades minimal footprint for deterministic behavior and cross-runtime consistency.

Why this exists

gofetch-wasm exists because JavaScript still lacks a standard HTTP client with:

sane defaults
consistent semantics
cross-runtime behavior

Until that exists, this project explores what such a primitive could look like.

What’s next

This is just the beginning.

Future work includes:

API refinement
improved streaming ergonomics
deeper TypeScript integration
better tooling and documentation

If you’ve ever rewritten the same HTTP wrapper for the third time, this project is for you.

-Nikos
Fourth Ally