WebAssembly Unleashed

WebAssembly keeps expanding beyond its original “run C/Rust in the browser” story, and this episode is a tour through the ideas and tooling that are shaping what comes next. Joel Moses and Oscar Spencer are joined by Conrad Watt, PhD., co-chair of the W3C WebAssembly Community Group, a key contributor to the formal memory and concurrency models, and an assistant professor at NTU Singapore, to talk about how formal methods, mechanized proofs, and specification engineering are influencing the evolution of Wasm. Conrad recounts how his academic work intersected with WebAssembly’s earliest formal semantics and why Wasm remains such a fertile “lens” for programming language research, spanning type systems, concurrency, and security. A central thread is the concurrency story: how WebAssembly threads grew from the JavaScript shared-memory model, what makes memory growth semantics difficult, and why getting threads fully integrated into the published W3C specification still has real engineering and tooling hurdles. The episode then zooms in on SpecTec, the domain-specific language now used to render the official WebAssembly 3.0 specification. Conrad explains why it exists, what problems it solves compared to raw LaTeX, and what remains unfinished, including the long-term goal of generating executable and provable semantics directly from the spec. They also talk about the looming challenge every web standard faces: specs only add features, they rarely remove them, and the community still doesn’t have a clean answer for avoiding complexity collapse. Finally, the episode closes by looking at Wasm’s intersection with AI, where its portability and safety model are strong assets, but GPU integration remains a key bottleneck, and by discussing how AI is changing education, including why in-person exams are making an unexpected comeback. If you’re interested in the research backbone of WebAssembly, this episode is the roadmap. Check out the recordings from Wasm Research Day 2026: https://www.youtube.com/playlist?list=PLUO8XobXx1SE

WASI Preview 3 is a turning point for WebAssembly outside the browser, and this episode explains why. F5's Joel Moses and Oscar Spencer are joined by Bailey Hayes, CTO of Cosmonic, to break down what “native async” really means for the component model, why it took two years to land, and how it changes the way we build polyglot, composable cloud systems. At the center of P3 is first-class async and concurrency in the canonical ABI. That isn’t just a nicer developer experience, it’s a host-level capability: runtimes can understand who’s waiting on what across composed components, propagate async handles through the stack, and apply backpressure using standardized stream types. Bailey walks through how this shows up in practical interfaces like WASI HTTP, where response bodies become streams and service chaining becomes far more natural, without the awkward P2-era workarounds. The conversation gets concrete on performance. Bailey shares real benchmark results showing order-of-magnitude gains when moving from serialized execution patterns to true concurrency, along with what changed mechanically from P2 to P3, including simpler interfaces, bidirectional streams, time zone support, better durations, and exit codes. They also talk about ecosystem impact: how P3 affects different languages, what it unlocks for JavaScript via JSPI, why Go still needs cooperative threading to be truly native, and why the rise of “vibed-out” runtimes is accelerating component model adoption. Bailey closes with what’s next in WASI evolution, her thoughts on Preview 4, and what additional capabilities could meaningfully expand what developers can do, including a future WebCrypto-style interface. If you’ve been waiting for WebAssembly to feel like a real distributed systems runtime, P3 is the milestone to understand. Read the WASI P3 launch blog: https://bytecodealliance.org/articles/WASI-0.3 Check out Bailey's work on Cosmonic.com

GPU acceleration is no longer “just for graphics,” and WebAssembly is stepping into a pivotal moment where portable compute means portable capabilities, not just portable code. In this episode of WebAssembly Unleashed, Joel Moses and Matt Yacobucci sit down with Mendy Berger from Cosmonic to unpack the latest shift in the WASI graphics ecosystem: why WASI WebGPU is being treated as the stable foundation, while higher-level display and surface work is moving into the more experimental wasi-gfx track. Mendy explains the core rationale behind the split. WebGPU, though new to many developers, has years of design maturity and broad vendor input behind it, making it a strong candidate for a stable interface. By contrast, “surface” and presentation APIs outside the browser don’t have the same level of polish yet, and need room to evolve quickly. The separation allows WebGPU to advance without being held back by the still-emerging display story, and it also supports non-graphics use cases where GPU compute matters without ever rendering a pixel. The conversation covers how WebGPU in WASI fits into the component model, why the WIT interface is so large, and what breaks when you push WIT into GPU-style corner cases like bitwise flags. They also dig into AI inference as a killer use case, including early work porting projects like llama.cpp and ONNX Runtime, and where WebGPU is a better fit than alternatives like WASI-NN or WebNN. Finally, Mendy shares where the specs stand today, what’s happening with Preview 3 and async, and how people can get involved through the WASI WebGPU repo, the wasi-gfx runtime work, and the weekly community meetings. If you care about GPUs, graphics, or bringing AI closer to where code runs, this episode lays out what’s changing and why it matters. Read The future of wasi-gfx and wasi:webgpu by Sean Isom & Mendy Berger: https://wasi-gfx.dev/blog/posts/future-of-wasi-gfx/ Get involved with WASI WebGPU: https://github.com/WebAssembly/wasi-webgpu Get involved with wasi-gfx: https://github.com/wasi-gfx

Debugging is where real engineering happens, and WebAssembly is reaching the point where “you can instrument it” isn’t good enough. In this episode of WebAssembly Unleashed, Joel Moses and Oscar Spencer sit down with Elizabeth Gilbert, a PhD candidate at Carnegie Mellon, to talk about Whamm: a DSL and framework designed to make instrumentation in Wasm less of a one-off engineering project and more of a repeatable, portable capability. Elizabeth explains how she arrived at WebAssembly through the developer tooling and fault-injection world, and why existing instrumentation approaches in Wasm often boil down to fragile bytecode rewriting. Whamm reframes the problem as “match and inject,” letting you express instrumentation at a higher level and then compile the probe logic as WebAssembly itself. That means you can write the instrumentation in any language that compiles to Wasm, while Whamm handles the hard parts: matching at opcodes, function entry/exit, branches and branch targets, imports, and other low-level control-flow details that are easy to get wrong. The conversation also covers an important evolution: running Whamm through an engine interface instead of pure rewriting. In that model, the runtime understands probes as probes, giving stronger isolation guarantees and opening the door to a standardized, portable instrumentation mechanism across engines. Finally, Elizabeth previews Splicer, her component-model work that can interpose on edges in a component composition graph and visualize those relationships, plus a candid look at where things get hard, especially around resources. If you care about observability, debugging, security analysis, or performance tooling for WebAssembly, this is a clear look at why the future may be less about more tools and more about better ways to describe instrumentation.

AI is making code generation feel effortless, but it’s also flooding systems with more untrusted, machine-written logic than most teams are prepared to safely run. In this episode of WebAssembly Unleashed, Joel Moses and Oscar Spencer zoom out on what that shift means for WebAssembly, security, and the future of software development, with special guest Ben Titzer, Director of the WebAssembly Research Institute at Carnegie Mellon and one of the principal creators of the WebAssembly standard. They start with a timely catalyst: a Bytecode Alliance Wasmtime security sprint where engineers used new AI models to stress-test the runtime and patch 11 vulnerabilities in just three weeks. From there, the conversation tackles the bigger question: if AI dissolves language boundaries for developers, does language still matter at runtime? Ben argues that it does, and that WebAssembly’s deterministic execution, portability, and lightweight sandboxing become even more valuable when code is generated on demand and needs to run safely across machines. The episode digs into how researchers are using WebAssembly to sandbox AI-generated code, why containers alone can be too heavyweight or too permissive, and how capability-based security is still underused as teams connect agents to tools and APIs. Ben also shares where AI is useful today, from generating tests to surfacing corner cases, and where it still struggles, especially with architecture and abstraction. The discussion closes with a look at active research in the Wasm ecosystem, including instrumentation languages, component interposition, dynamic language performance, kernel interfaces, and deterministic record-and-replay, plus an honest take on how AI is reshaping how students learn and how educators assess real understanding. Read the Wasmtime blog: https://bytecodealliance.org/articles/wasmtime-security-advisories