Blazor WASM's Deputy Thread Model Will Break JavaScript Interop - Here's Why That Matters

The Problem

Microsoft is changing how .NET runs inside WebAssembly. When you enable threading with <WasmEnableThreads>true</WasmEnableThreads>, the entire .NET runtime moves off the browser's main thread and onto a background Web Worker — what they call the "Deputy Thread" model.

This sounds like a good idea on paper. The UI stays responsive. .NET gets real threads. Everyone wins.

Except it breaks JavaScript interop. Not in a subtle, edge-case way. It breaks it fundamentally.

What Actually Happens

In traditional Blazor WASM (no threading), .NET and JavaScript share the same thread. When JavaScript calls DotNet.invokeMethod, the CPU jumps from the JS stack to the C# stack and back. It's fast. It's synchronous. It works.

In the Deputy Thread model, .NET lives in a Web Worker. JavaScript lives on the UI thread. They're in different worlds. When JavaScript tries to call DotNet.invokeMethod, the UI thread would have to block while waiting for the worker to respond.

Browsers don't allow that. The UI thread is forbidden from blocking on a worker. So the .NET runtime throws:

Error: Cannot call synchronous C# methods.

And that's the end of synchronous JS-to-.NET communication.

Why "Just Use Async" Doesn't Work

The most common response to this concern is: "just make everything async." This misunderstands how the browser works.

The JavaScript event model requires synchronous handling in many scenarios. These aren't obscure edge cases — they're core browser functionality:

event.preventDefault()

element.addEventListener('submit', (event) => {

    // This MUST happen synchronously, right here, right now.

    // If you await a response from a worker thread,

    // the browser has already submitted the form.

    event.preventDefault();

});

You cannot await a response from a .NET worker and then call preventDefault(). By the time the worker responds, the browser has already processed the default action. The form is submitted. The navigation has happened. The drag operation completed.

event.stopImmediatePropagation()

Same constraint. Other listeners have already fired by the time an async response arrives.

beforeunload

window.addEventListener('beforeunload', (event) => {

    // Must return synchronously. No promises. No awaiting workers.

    event.returnValue = 'Are you sure?';

});

Synchronous Property Access

Many JavaScript APIs expose synchronous getters and setters. A C# wrapper that aims to match the JS API surface needs to read these values synchronously. In the Deputy Thread model, every property access becomes an async round-trip to a worker.

The Real-World Impact

I maintain (90,000+ downloads) has provided multi-threading for Blazor WASM for years — without the Deputy Thread model. The architecture is straightforward:

1. The main .NET instance stays on the browser's UI thread


2. Synchronous JS interop works exactly as designed


3. Heavy computation dispatches to background Web Workers explicitly


4. The developer controls which work goes where

This is how threading should work in the browser. The main thread handles the UI and synchronous JS communication. Workers handle the heavy lifting. The developer decides what runs where.

Microsoft's approach inverts this: move everything to a worker, then try to proxy the UI. It solves the "UI jank during heavy computation" problem, but it does so by severing the synchronous link between .NET and the browser.

What I'm Asking For

I'm not asking Microsoft to abandon the Deputy Thread model. It has legitimate value for applications that prioritize background computation over DOM fidelity.

I'm asking for a choice:

<PropertyGroup>

    <WasmEnableThreads>true</WasmEnableThreads>

    <!-- Keep .NET on the UI thread, dispatch work to workers -->

    <WasmKeepMainThreadOnUI>true</WasmKeepMainThreadOnUI>

</PropertyGroup>

In this mode:

• 
  Program.Main runs on the browser's UI thread


• Synchronous JS interop works normally


• 
  Task.Run and thread pool work dispatch to background Web Workers


• Blocking primitives (lock, Thread.Sleep) work on background threads, throw on the UI thread (the browser already enforces this)


• Libraries that depend on synchronous interop continue to function

Developers who want full Deputy Thread isolation can still opt into it. But it shouldn't be the only option.

The Bigger Concern

My deeper worry is the trajectory. If the Deputy Thread becomes the only supported execution model — even for single-threaded builds — every Blazor WASM application that depends on synchronous JS interop will break. Not just SpawnDev. Every library. Every application.

The browser is a local execution environment, not a remote server. .NET in the browser should be able to talk to JavaScript the same way JavaScript talks to itself — synchronously when needed, asynchronously when preferred.

Where This Is Being Discussed

• 
  — Where the threading architecture decisions are actually made

If this affects your work, add your voice to those issues. The more the team hears from developers who depend on synchronous interop, the more likely we are to get a hybrid option.

I'm library ecosystem for Blazor WebAssembly. I've been building high-performance browser applications with .NET for years, and I want to keep doing it.