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