[wasm] Request: Option to keep .NET main thread on browser UI thread when threading is enabled

[LostBeard]

Description

When <WasmEnableThreads>true</WasmEnableThreads> is set, the .NET runtime moves entirely to a background Web Worker (the "Deputy Thread" model). This makes DotNet.invokeMethod — synchronous JS-to-.NET calls — impossible, because the browser's UI thread cannot block while waiting for a response from a worker.

I'm requesting a supported configuration option that enables .NET threading (thread pool, Task.Run, System.Threading) while keeping the main .NET entry point on the browser's UI thread.

Background

I maintain the SpawnDev.BlazorJS ecosystem — 41 NuGet packages, 323,000+ total downloads — which provides typed C# wrappers for JavaScript APIs in Blazor WebAssembly. This library depends on synchronous JS-to-.NET interop (DotNet.invokeMethod) because the JavaScript specification requires synchronous handling in many scenarios:

• event.preventDefault() must be called synchronously within the handler
• event.stopImmediatePropagation() — same constraint
• beforeunload requires a synchronous return value
• Synchronous property getters on JS objects
• Callback-driven APIs that expect synchronous returns

These are not edge cases. These are fundamental browser APIs that cannot be handled asynchronously.

Proposed Behavior

A configuration like:

<PropertyGroup>
    <WasmEnableThreads>true</WasmEnableThreads>
    <WasmMainThreadOnUI>true</WasmMainThreadOnUI>
</PropertyGroup>

When enabled:

• Program.Main executes on the browser's UI thread (as it does today without threading)
• Synchronous JS interop (DotNet.invokeMethod, [JSExport] with sync signatures) works normally
• Task.Run, ThreadPool, and new Thread() dispatch to background Web Workers
• Blocking primitives (lock, Monitor.Enter, Thread.Sleep) work on background threads but throw on the UI thread (this is already the browser's constraint)

This is architecturally the same model that SpawnDev.BlazorJS.WebWorkers (90,000+ downloads) has used successfully for years: main .NET on the UI thread, heavy work dispatched to workers explicitly.

Why This Matters

Without this option, any .NET library that provides synchronous JavaScript interop is broken when threading is enabled. This affects:

• SpawnDev.BlazorJS and its 41-package ecosystem (WebRTC, WebGPU, WebTorrent, Canvas, Crypto, etc.)
• Any third-party library wrapping synchronous JS APIs
• Any application handling DOM events that require synchronous responses

The Deputy Thread model is valuable for applications that prioritize background computation over DOM fidelity. But it should not be the only option. Developers who need synchronous JS interop should be able to opt into threading without losing it.

Related Issues

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

Environment

• .NET 10
• Blazor WebAssembly
• All modern browsers (Chrome, Edge, Firefox, Safari)

[LostBeard]

• Related discussion: Make Blazor WebAssembly work on multithreaded runtime aspnetcore#54365 (comment)
• Detailed technical breakdown: https://dev.to/lostbeard/blazor-wasms-deputy-thread-model-will-break-javascript-interop-heres-why-that-matters-1n9n

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.

[pavelsavara]

For the ST build, it seems that we will keep supporting running managed code on the UI thread for foreseeable future.

Why this is feature request: MT is not shipped/supported yet in Net11 or before. MT is just an experiment so far.
It may seem that we don't care about MT, but we do, those are difficult problems to solve.

The main challenges with this idea in this issue are:

• you can't block in the UI thread. You can spin-wait only. When you spin-wait, other async things in the browser don't work. There is whole mayhem of scenarios which deadlock.
• general C# code can't be expected to behave differently on main thread. Blocking works (like on server) or it doesn't work (like in ST blazor) in the whole application in the same way, on all threads, all pieces of code. We are not going to support mixed mode threading model.

I spent significant time exploring our options in 2023, here is condensed outcome of those experiments.

I realize there are browser APIs that need to compute some results synchronously. Most of them could be avoided by making the decision in synchronously in JS based on pre-calculated data, that's how Blazor interactive server works with preventDefault(). Or double buffering for requestAnimationFrame().

The new idea is that whole MT emscripten/posix could be started in the worker. The difference it makes is that the posix emulator core would not suffer from spin-wait deadlocks on the UI thread. This idea was not even prototyped yet. It would make synchronous spin-blocking on UI thread less risky. I'm not sure it gives you hope. It would not happen before Net12 for sure.

Admittedly, this would be just another tradeoff. What Color is Your Function problems don't go away easily, the problems could only be shifted to different layer.