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