WASM on

Lesson 8: The Component Model — Composable WASM modules

Fri, 18 Jul 2025 10:41:09 +0000

Here’s a scenario that actually happened to me: I had a data validation library written in Rust, a business logic layer in Go, and a reporting module that a client had written in Python. Three languages, three teams, three deployment stories. Traditionally, this means three services talking over HTTP with serialization overhead, network latency, and a distributed systems headache.

With the Component Model, I compiled all three to WASM components, composed them into a single module, and ran the whole pipeline in one process. No network calls, no serialization, no containers. Function calls across language boundaries, at native speed.

Lesson 7: WASI — WebAssembly beyond the browser

Tue, 15 Jul 2025 19:22:41 +0000

About a year ago, I deployed a Rust function as a Cloudflare Worker using WASM. Cold start: 0.5ms. Compare that to a Lambda function in any other language — 50-500ms on a cold start. That’s when I realized WASI isn’t some academic curiosity. It’s the future of server-side compute.

Solomon Hykes — the guy who created Docker — tweeted this back in 2019: “If WASM+WASI existed in 2008, we wouldn’t have needed to create Docker.” He wasn’t being hyperbolic. WASI gives you true sandboxing, near-native performance, cross-platform portability, and sub-millisecond startup. It’s what containers promised, but at a fundamentally lower level.

Lesson 6: Multi-Threaded WASM — SharedArrayBuffer and atomics

Sun, 13 Jul 2025 07:55:18 +0000

I got a 4.2x speedup on a real-time audio processing pipeline by adding threads to my WASM module. Four threads, 4.2x faster — nearly linear scaling. That almost never happens in practice, but WASM threading hits a sweet spot: the workloads that justify WASM in the first place (heavy computation, large data) are exactly the workloads that parallelize well.

The bad news? Getting threads working in WASM is more involved than std::thread::spawn. There are browser security requirements, Web Worker coordination, shared memory semantics, and a whole build pipeline to figure out. Let me walk you through all of it.

Lesson 5: WASM Performance — When it beats JavaScript

Thu, 10 Jul 2025 16:08:51 +0000

“WASM is faster than JavaScript.” I’ve heard this so many times, and it drives me nuts — not because it’s wrong, but because it’s incomplete. WASM can be faster than JavaScript. It can also be slower. The difference depends on what you’re doing, how you’re crossing the JS↔WASM boundary, and whether you’ve hit the specific scenarios where WASM’s architecture actually gives you an advantage.

I ran benchmarks for months to figure out where the real boundaries are. Let me show you the data.

Lesson 4: Leptos, Yew, Dioxus — Full-stack Rust

Mon, 07 Jul 2025 09:17:33 +0000

After building that todo list with raw web-sys in Lesson 3, I think we can all agree: manually managing DOM nodes, closures wrapped in Rc<RefCell<Option<Closure<dyn FnMut()>>>>, and string-based style attributes isn’t how anyone wants to build a real application. That’s where Rust frontend frameworks come in. And we’ve got three serious contenders — each with a different philosophy about how to build web UIs.

I’ve built side projects with all three. Let me tell you what actually matters when choosing between them.

Lesson 3: Manipulating the DOM from Rust — Web without JavaScript

Sat, 05 Jul 2025 11:33:47 +0000

There’s something deeply satisfying about writing document.create_element("div") in Rust and watching it actually work in a browser. It’s also, if I’m being honest, kind of painful — because web-sys wraps every single Web API call in Result types, and you end up with .unwrap() chains that would make any Rustacean cringe. But once you build the right abstractions on top, it becomes surprisingly pleasant. Let me show you how I got there.

Lesson 2: wasm-bindgen — Bridging Rust and JavaScript

Thu, 03 Jul 2025 14:12:05 +0000

The first time I looked at what #[wasm_bindgen] actually generates, I was equal parts impressed and horrified. Impressed because it seamlessly bridges two fundamentally different type systems. Horrified because the generated code is a labyrinth of pointer arithmetic, descriptor tables, and heap management. But here’s the thing — you don’t need to understand every line of generated code. You do need to understand the model, because when things go wrong (and they will), the model is what helps you debug.

Lesson 1: Rust to WebAssembly — Why and how

Tue, 01 Jul 2025 08:45:22 +0000

I was optimizing a client-side image processing pipeline last year — think heavy convolutions, histogram equalization, color space conversions. The JavaScript implementation was doing about 12 frames per second. I rewrote the core loops in Rust, compiled to WebAssembly, and hit 55 fps. Same browser. Same machine. That’s the moment WebAssembly stopped being a curiosity and became a tool I actually reach for.

But let me be real: getting there wasn’t a straight line. The tooling has rough edges, the mental model is different from writing server-side Rust, and half the blog posts out there show you how to add two numbers in WASM and call it a tutorial. That’s not what we’re doing here.

Lesson 2: Server-Side WASM — WASI, edge computing, and the universal binary

Fri, 11 Oct 2024 00:00:00 +0000

When most people talk about WebAssembly, they mean the browser. That’s where it started, that’s where the tutorials are, and that’s where most of the public discourse still lives. But the more interesting story for backend engineers is what happens when you take the same sandboxed, portable binary model and apply it on the server.

Server-side WebAssembly — specifically WebAssembly with WASI (the WebAssembly System Interface) — is not a toy. Cloudflare Workers runs WASM. Fastly Compute runs WASM. Fermyon Spin is built on it. The pattern is spreading from edge providers into general-purpose infrastructure. Understanding it now puts you ahead of where most backend engineers are.

Lesson 1: WASM from Go — Compile Go to WebAssembly and run it anywhere

Fri, 12 Jul 2024 00:00:00 +0000

I came to WebAssembly skeptically. The pitch — “run code anywhere, at near-native speed, in a sandboxed environment” — sounded like the kind of claim that looks great in a conference talk and falls apart in production. It took a specific use case to make me take it seriously: I needed to run the same validation logic in three environments — a Go backend, a JavaScript frontend, and a CLI tool — without maintaining three separate implementations of the same business rules.