# Stride

Stride doesn't have a working WebAssembly target — blocked upstream.

Source: https://docs.wavedash.com/engines/stride

Stride can't run in the browser today. The framework transitively pulls in Silk.NET's native SDL bindings, which declare pinvoke callbacks whose parameter types aren't blittable — Blazor WebAssembly's AOT compiler rejects those at link time, so the WASM build fails before it produces an artifact.

This is an **upstream problem** in Stride / Silk.NET, not something Wavedash can fix on our side. Until they ship WASM-compatible bindings, there's no clean path for a Stride game to Wavedash (or any other web host).

Upstream issue tracking this: [stride3d/stride#70](https://github.com/stride3d/stride/issues/70). Star it if you want notifications.

Workarounds we've seen in the wild:

- Pin to an older Silk.NET that sidesteps the specific callback and stub the SDL surface Stride touches. Fragile and unmaintained.
- Run Stride headless on a server and stream frames to the browser. That's not a Wavedash-hosted build — you'd just embed the stream in whatever host you prefer.

Neither is a drop-in replacement for a real WASM target. If you're evaluating engines for a web game and need C#, [KNI](/engines/kni) (MonoGame-compatible BlazorGL fork) is the practical choice today.