Should the Deputy Thread model be the only path to .NET WASM threading?

[LostBeard]

Question for the panel:

When WasmEnableThreads is enabled, .NET moves entirely to a background Web Worker, making synchronous JS-to-.NET calls (DotNet.invokeMethod) impossible. This breaks libraries that provide 1-to-1 JavaScript API wrappers — including SpawnDev.BlazorJS (147,000+ downloads) — because the JavaScript spec requires synchronous handling for operations like event.preventDefault() and beforeunload.

Community-built solutions like SpawnDev.BlazorJS.WebWorkers (90,000+ downloads) already provide multi-threading while keeping the main .NET instance on the UI thread, preserving synchronous interop.

The question: Is there a plan to offer a hybrid mode — threading enabled but .NET stays on the main thread — or is the Deputy Thread the only supported path forward? And is running .NET on the browser's main thread a long-term supported execution model?

Related issue: #54365

• Related discussion: Make Blazor WebAssembly work on multithreaded runtime #54365 (comment)
• Runtime issue: [wasm] Request: Option to keep .NET main thread on browser UI thread when threading is enabled runtime#126438
• Technical breakdown: https://dev.to/lostbeard/blazor-wasms-deputy-thread-model-will-break-javascript-interop-heres-why-that-matters-1n9n

[MostafaChronic]

This is a phenomenal and highly critical question for anyone building deep, low-level JavaScript wrappers or real-time web applications in the Blazor ecosystem.

To give you a direct answer based on the architectural direction of the .NET WebAssembly runtime: No, there is currently no plan to offer an official "hybrid" mode where .NET stays on the UI thread while WasmEnableThreads is active. The Deputy Thread model is the intended and supported long-term path forward for multi-threading.

Here is the architectural rationale behind this decision, along with the implications for the ecosystem:

1. The Core Issue: Browser Deadlock Prevention
   The fundamental reason .NET moves entirely to a Web Worker when threading is enabled is to prevent catastrophic UI deadlocks.
   If the main .NET runtime instance remained on the browser's UI thread, any synchronous thread synchronization in C# (such as a Task.Wait(), Monitor.Enter, or lock statement) that accidentally blocks waiting for a background Web Worker would instantly freeze the entire browser tab.

To ensure platform safety and prevent unstable web apps, the team designed the Deputy Thread Model. In this model, the UI thread acts purely as a thin proxy for rendering and event forwarding, while the entire runtime lives off-main-thread.

2. The Status of UI-Thread Execution
   Running .NET on the browser's UI thread is, and will remain, a long-term supported execution model, but only for single-threaded applications. Once you cross the line into native WebAssembly multi-threading (WasmEnableThreads=true), the runtime must live in a worker. Microsoft prioritizes ecosystem stability and deadlock mitigation over backward compatibility for synchronous JS interop.

3. How the Ecosystem Must Adapt
   Because crossing the Web Worker boundary via postMessage is inherently asynchronous, traditional synchronous JS-to-.NET calls (DotNet.invokeMethod) are technically impossible in this mode. This breaks native browser specs like event.preventDefault() or beforeunload which require synchronous execution.

To solve this, developers and library maintainers are moving toward two design patterns:

Declarative Interop (Pre-Event Registration): Instead of waiting for .NET to dynamically decide whether to prevent a default behavior, the intention must be registered on the JS side before the event bubbles up (similar to how Blazor uses @OnClick:preventDefault).

JS Isolation for UI-Sensitive Loops: Logic that requires tight, synchronous coupling with browser APIs (like Web Audio, precise canvas loops, or input interceptors) must be authored natively in JavaScript/TypeScript on the UI thread, bypassing .NET execution for that specific immediate loop.

While community solutions like SpawnDev.BlazorJS.WebWorkers are incredible engineering feats for keeping .NET on the UI thread, they require developers to manually ensure they don't deadlock their application—a risk that the official framework cannot safely introduce to the broader developer audience.