WebAssembly Unleashed

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

WebAssembly Unleashed goes hands-on with a topic that shows up every time polished architectures collide with real production: programmability. Coming to you from F5's AppWorld 2026, hosts Joel Moses and Oscar Spencer are joined by WorldTech IT's Austin Geraci and Josh Brooks to talk about what actually happens when customers need traffic behavior that “shouldn’t exist,” but still has to work reliably at scale.

The conversation moves from the reality of messy APIs and legacy constraints to the practical value of a programmable data plane. Austin and Josh share examples ranging from deterministic routing based on fields buried inside JSON payloads to deeply unglamorous but essential protocol surgery, including binary-level LDAP manipulation and SAML/OAuth edge cases that break whenever an upstream system refuses to behave. The common thread is clear: when the app team can’t change the app, the network and security layers become the integration surface.

They also dig into why language choice still matters, even in the age of AI-assisted coding. Tooling ecosystems, native support for things like JSON parsing, and access to third-party libraries can turn “weeks of custom glue” into something maintainable. That’s where WebAssembly enters the picture: portable components and familiar languages that can run close to the traffic without forcing teams into legacy scripting or vendor-specific dialects.

If you’re building AI-enabled applications, modernizing older systems, or trying to keep pace with constantly changing APIs, this episode makes the case that programmable middleware isn’t optional. It’s how you avoid waiting on feature releases, adapt safely, and turn a good fit into a production-ready one.

WebAssembly is usually framed as an application runtime story, but at AppWorld 2026 in Las Vegas, WebAssembly Unleashed shifts the spotlight to a more urgent frontier: data. As AI architectures get hungrier and more distributed, performance and security constraints are moving closer to the data store itself. In this episode, Joel Moses and co-host Oscar Spencer explore why WebAssembly components could become the connective tissue between data-intensive AI systems and the storage infrastructure that feeds them.
They’re joined by Ugur Tigli, CTO of MinIO, to break down how modern AI workloads stress storage in very different ways, from throughput-heavy training and RAG pipelines to latency-sensitive inference. Ugur explains why keeping GPUs fed is now an economic necessity, how MinIO optimizes for saturating networks, and how techniques like erasure coding and SIMD offload help keep CPU and memory overhead low across diverse hardware targets.
If you’re trying to understand where WebAssembly fits beyond the browser and beyond app logic, this episode offers a practical view of Wasm as a data-adjacent execution layer for real-world AI.