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 true, 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.

Enter fullscreen mode

Exit fullscreen mode

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(); });

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(); });

Enter fullscreen mode

Exit fullscreen mode

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?'; });

window.addEventListener('beforeunload', (event) => {  // Must return synchronously. No promises. No awaiting workers.  event.returnValue = 'Are you sure?'; });

Enter fullscreen mode

Exit fullscreen mode

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 SpawnDev.BlazorJS — a library that provides typed C# wrappers for JavaScript APIs in Blazor WebAssembly. It's part of a 41-package ecosystem with over 323,000 total NuGet downloads, covering WebRTC, WebGPU, WebTorrent, Canvas, Crypto, IndexedDB, Streams, and dozens of other browser APIs.

The library exists because Microsoft's built-in JS interop is incomplete. SpawnDev.BlazorJS fills the gaps with full, high-fidelity 1-to-1 mappings of the JavaScript specification.

The Deputy Thread model breaks this library. Not partially — any operation that requires DotNet.invokeMethod fails when .NET is on a worker.

But this isn't just about my library. Any Blazor WASM project that:

• Handles DOM events requiring synchronous responses

• Wraps synchronous JavaScript APIs

• Uses synchronous callbacks from JS to .NET

• Builds real-time applications (WebRTC, WebSocket handlers, canvas rendering)

...will hit this wall.

We Already Solved Multi-Threading Without Breaking Interop

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

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

• Synchronous JS interop works exactly as designed

• Heavy computation dispatches to background Web Workers explicitly

• 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:

  true

  true

true `

Enter fullscreen mode

Exit fullscreen mode

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

• dotnet/aspnetcore#54365 — "Make Blazor WebAssembly work on multithreaded runtime"

• dotnet/runtime — 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 Todd Tanner (@LostBeard), author of the SpawnDev library ecosystem for Blazor WebAssembly. I've been building high-performance browser applications with .NET for years, and I want to keep doing it.