Thanks for contacting us, @BlenderMender.
WASM 1.0 spec doesn't include real multithreading, and this is the spec we currently target. We expect improvements in this area in the future.

Wonder if the actual issue is letting JS be multithreaded and some peoples fear that this will cause some disturbance because threadings.
If this is the case I have the follow suggestion:

• Let the JS use 1 thread locked only for it - emulating the current state of the things, and the rest threads be free for background work of the C# application.

I would dive deep into blazor (without any return) if there would be support for multithreading for client side. Make it happen!

I've created a small library called BlazorWorker which creates a new dotnet process using web workers. It's very similar to multithreading, main difference being no shared memory, only message passing @BlenderMender @Marcin-Perz I would appreciate your feedback on the API, to see if it's a path worth pursuing in the meantime.

This is blocked on mono/mono#12453

Thumbs up for for proper .NET Tasks and Threads

Hi, yes please make it happen. Thanks in avance.

Given the current limitations around browser support we’ve decided to push this work out of .NET 5.
We will reevaluate the state of threading support in browsers during .NET 6 planning phase.

Good lords. But this is the most expected thing.
The blazor boilerplate and the way the .NET works, and the whole ideology of client side .NET project requires multithreading and real async to work correctly.
I vote to back off a bunch of other features and push for multithreading than vice-versa..

Does this mean we will have to wait 2021 november for threading support?

Alright: With the current Firefox 79 the SharedArrayBuffers were reactivated. They were temporarily disabled because of Spectre. Also in Firefox 79, threads for WASM were released: https://hacks.mozilla.org/2020/07/firefox-79/ (note: SharedArrayBuffers was one prerequisite for threads in WASM)

Thus, it should be possible for .NET (Mono) to implement threadding, right?

Seems like again our trust into MS Frameworks is going to be betrayed.
Blazor WebASM currently performing the worst from all available frameworks, because it's awful JS interloop and lack of multi-threading which is essential for .NET.

Please MS team - do something. Do not kill it before it's born, and do it now, December is going to be awfully late, since the disappointment will start taking space.

@dt200r Hey, it's same for me. Temporarily while waiting for this feature. My work around: using web worker with JavaScript interop unmarshall calling. It's not really good, but get the job done.

I am starting to feel like web-browser should just be a docker with pretty UI.
Btw how long are we going to wait for Web-assembly to implement threads? Whenever we are trying to do something we are always burdened by the restrains of various technology venders we are relying on, the surface area of just the client side of the of the web is too big. Then the back end is fine because everything gets turned into 0 and 1 through the cable anyways.
Just kill webassembly at this point it's already been years since their last release

This is the state of modern applications btw, everything is running on top of something, blocked by the delay of implementations of features in the underlying platform, when the good old days you just give people your app, and it runs as long they have a cpu that the program was compiled for.

I am hoping, since people are running windows, let's have a single browser that's in the operating system, there will be no chromes on windows, unless they interface it with the OS's browser, then we can do crazy things like run any code in any language targetting this browser, which runs on .NET, which then expose pretty UI letting people maybe design it using html & css, but also allowing c# to manipulate UI like xamarin, it's going to be a major platform that evolves along with .NET, providing many benifit and the freedom to make features available, without worrying about what browsers your users have. if they run windows they can visit your website.

this technology can be duo-cored, one that still use chromium for legacy websites and one for new-compiled-websites, and when you put the word legacy out there websites that pretend this isn't a thing will die out fast

#38745

Multi threading should be supported on chrome based browsers. Multi threading should be implemented in terms of the task pool and scheduler. Then if running on an unsupported browser the task pool is configured so that it only has access to one real thread. Then all logic written will work on a single threaded browser, but will receive a serious uplift in performance when running on chrome and N threads are available for the task pool to utilize.

Are there any updates on multi threading for blazor wasm? ALso don't give me that nonsense that threads aren't supported in web assembly, take a gander:

https://web.dev/webassembly-threads/

In summary web assembly supports mutli threading, chrome based browsers support multi threading, and you could reasonably develop a multi threading system in blazor wasm using the task pool. Anything that relies on Task.run would then benefit greatly.

Multi threading should be supported on chrome based browsers. Multi threading should be implemented in terms of the task pool and scheduler. Then if running on an unsupported browser the task pool is configured so that it only has access to one real thread. Then all logic written will work on a single threaded browser, but will receive a serious uplift in performance when running on chrome and N threads are available for the task pool to utilize.

Are there any updates on multi threading for blazor wasm? ALso don't give me that nonsense that threads aren't supported in web assembly, take a gander:

https://web.dev/webassembly-threads/

In summary web assembly supports mutli threading, chrome based browsers support multi threading, and you could reasonably develop a multi threading system in blazor wasm using the task pool. Anything that relies on Task.run would then benefit greatly.

Or abandon blazor-wasm today for MAUI-blazor

@Xyncgas: Or abandon blazor-wasm today for MAUI-blazor

For my Use Cases, both are required which is what makes Blazor so attractive. Customers need rich SaaS experiences through a browser? Blazor. Customers need a fast native mobile experience? Same Blazor app wrapped in MAUI. Need to augment legacy OnPrem tooling with new editors that you also need in SaaS? MAUI-Blazor or WPF-Balzor.

I started coding before the web existed. In all the web years, it was like, "Ok, we're building a desktop app, we can use technologies x, y, z", compared to a, "We're building a web app, we can only use technologies p, d, q", or, We're building a mobile app, we need something different that the prior 2. There's just not enough money or developers to satisfy those three and deliver fast with quality. (when the rubber meets the budget road).

With Blazor, write once and basically use everywhere. True multi-threading support seals the deal.

This is really needed for Blazor. In our case, the main purpose of Blazor is to be able to add another UI layer (web) on top of portable libraries for which we already have Windows, iOS and Android UI layers

Our company's C# libraries all relie heavily on Tasks and multi-threading, and by reading the comments here, I believe we're not the only ones

For us, this feature is definitely on the top 3 for Blazor !

I agree with @chingham but also have a vested interest in how multithreading might impact startup time of both the mono runtime and blazor and how this might prevent UI locking when loading a prerendered blazor wasm application.

Any thoughts on this?

I agree with @chingham but also have a vested interest in how multithreading might impact startup time of both the mono runtime and blazor and how this might prevent UI locking when loading a prerendered blazor wasm application.

Any thoughts on this?

I don't imagine it would affect loading times for blazor at all. I mean all of the task library logic is already loaded as part of standard blazor wasm. All that would happen is the task pool gets access to multiple threads if needed. Task pool threads get started up as needed in the background

I agree with @chingham but also have a vested interest in how multithreading might impact startup time of both the mono runtime and blazor and how this might prevent UI locking when loading a prerendered blazor wasm application.
Any thoughts on this?

I don't imagine it would affect loading times for blazor at all. I mean all of the task library logic is already loaded as part of standard blazor wasm. All that would happen is the task pool gets access to multiple threads if needed. Task pool threads get started up as needed in the background

Ah fair but I was thinking more in regards to starting the mono runtime without locking input fields, currently we have users waiting upwards of 20 seconds on old ios/android devices for the mono runtime to load before being able to use an input field.

I appreciate that the runtime needs time to start, but it seems to me that multithreading in the runtime would allow this to be handled without blocking the UI thread.

The poor startup time of blazor webassembly is my only real gripe, I would even be able to allow being locked to a single thread if the startup time was not so poor.

But maybe I am misunderstanding the architecture here?

are you sure that it is not because of the network speed @mattgenious?

are you sure that it is not because of the network speed @mattgenious?

100% I can see the "mono runtime ready" event firing after 20 seconds and then the UI locking stops 😊

are you sure that it is not because of the network speed @mattgenious?

100% I can see the "mono runtime ready" event firing after 20 seconds and then the UI locking stops 😊

Also given that the best case startup time on firefox and chrome is around 1.67 seconds on a 24-core cpu with 32g ram it doesn't surprise me that much that some older mobile devices like iPhone 6s and Oneplus Nord have massive load times. I just wish it weren't so 😊

I have feeling that this unreasonable delaying of Mono support of multithreading is a favor to Apple devices which does not support real multithreading. I am really curious when Microsoft shall stop doing favor to other companies and put his own things first. ( Point the favor to dump Flash, which was one of the things lacking the other platforms, and users were really into.
Billions dollars per year were made just from the Flash games in Facebook alone, and Microsoft easily gave it on it, practically ditching 95% of his users gaming needs - a business worth currently at least 600 billion dollars, which is currently divided between Google and Apple instead of Microsoft just pay a group of programmers to help Adobe fix the "bad exploits" and keep going with it.
Just the same story repeat now with Mono as I am seeing the things from my probably wrong point of view ;)

I have feeling that this unreasonable delaying of Mono support of multithreading is a favor to Apple devices which does not support real multithreading. I am really curious when Microsoft shall stop doing favor to other companies and put his own things first. ( Point the favor to dump Flash, which was one of the things lacking the other platforms, and users were really into.

Billions dollars per year were made just from the Flash games in Facebook alone, and Microsoft easily gave it on it, practically ditching 95% of his users gaming needs - a business worth currently at least 600 billion dollars, which is currently divided between Google and Apple instead of Microsoft just pay a group of programmers to help Adobe fix the "bad exploits" and keep going with it.

Just the same story repeat now with Mono as I am seeing the things from my probably wrong point of view ;)

While I appreciate the sentiment I feel that this might be a bit off topic and according to https://webassembly.org/roadmap/ the ios safari browser actually seems to support real multithreading if I'm not misunderstanding something.

I would also like to point out that I think that waiting for webassembly to finish its spec for multithreading seems reasonable, were it not for the fact that most browsers have already implemented support based on the draft specification.

To ensure the feasability of Blazor Webassembly as a potentially broadly used front end framework for SPA's, I feel we have to make it a priority that the startup time for the mono runtime and subsequent Blazor framework be optimizid as much as possible 😊

@mattgenious Would it help to improve the startup speed with Lazy Loading? Sorry if this is off topic.

@danroth27 @mkArtakMSFT running multi threading require SharedArrayBuffer but SharedArrayBuffer is only available to pages that are cross-origin isolated. in actual deployment of wasm app do we need to add Cross-Origin-Embedder-Policy: require-corp and Cross-Origin-Opener-Policy: same-origin headers manually or it will handled automatically?

I would like to not that all of the limitations before the multithreading is artificial created to support the current ideology of the single threading javascript, and maybe it is time to look beyond javascript, since this was the original idea of Blazor. Isn't it ?

@mattgenious Would it help to improve the startup speed with Lazy Loading? Sorry if this is off topic.

It wouldn't make a difference as the mono runtime has to start before even a smaller assembly is loaded and will still be doing so on a single thread effectively blocking the UI thread. But I appreciate the input :-)

@mattgenious Would it help to improve the startup speed with Lazy Loading? Sorry if this is off topic.

It wouldn't make a difference as the mono runtime has to start before even a smaller assembly is loaded and will still be doing so on a single thread effectively blocking the UI thread. But I appreciate the input :-)

So is the problem a CPU cycles issue where once the mono runtime has been initially transferred to the client, there is a lot of processing going on that needs to occur before things could start? Or is this an initial transfer issue such that if you were to use http3 it could accelerate the initial load since all the files could be transferred in parallel on start over udp like protocol?

If its a processing problem why can't everything be preprocessed on the server side and then sent to the client which can run as is?

Is it just me or discussion has shifted from multithreading to loading times ?

@mattgenious Would it help to improve the startup speed with Lazy Loading? Sorry if this is off topic.

It wouldn't make a difference as the mono runtime has to start before even a smaller assembly is loaded and will still be doing so on a single thread effectively blocking the UI thread. But I appreciate the input :-)

So is the problem a CPU cycles issue where once the mono runtime has been initially transferred to the client, there is a lot of processing going on that needs to occur before things could start? Or is this an initial transfer issue such that if you were to use http3 it could accelerate the initial load since all the files could be transferred in parallel on start over udp like protocol?

If its a processing problem why can't everything be preprocessed on the server side and then sent to the client which can run as is?

We are prerendering the application on the server side, serving it, then starting up the wasm app.
The behavior is as follows:

• Html is rendered instantly and starts loading the webassembly (which is cached in this case)
• For less than a second the UI is responsive and then locks up as startup of the mono runtime and app is handled
• depending on the device it takes between 1.6 seconds and 29 seconds (tested today on an iPhone 5s with ios 12.2) before UI is responsive again.

I am certain that it is not the transfer of files but the processing of mono and blazor taking up almost all of that wait time as I have tested many times with everything cached, and when it is not, the UI is not locked while the webassembly app is being downloaded, only when startup of the runtime is initiated.

We are prerendering the application on the server side, serving it, then starting up the wasm app. The behavior is as follows:

• Html is rendered instantly and starts loading the webassembly (which is cached in this case)
• For less than a second the UI is responsive and then locks up as startup of the mono runtime and app is handled
• depending on the device it takes between 1.6 seconds and 29 seconds (tested today on an iPhone 5s with ios 12.2) before UI is responsive again.

I am certain that it is not the transfer of files but the processing of mono and blazor taking up almost all of that wait time as I have tested many times with everything cached, and when it is not, the UI is not locked while the webassembly app is being downloaded, only when startup of the runtime is initiated.

@mattgenious If you haven't already, I think you should open a separate issue for this so that we can investigate your specific startup performance issue.

We are prerendering the application on the server side, serving it, then starting up the wasm app. The behavior is as follows:

• Html is rendered instantly and starts loading the webassembly (which is cached in this case)

• For less than a second the UI is responsive and then locks up as startup of the mono runtime and app is handled

• depending on the device it takes between 1.6 seconds and 29 seconds (tested today on an iPhone 5s with ios 12.2) before UI is responsive again.

I am certain that it is not the transfer of files but the processing of mono and blazor taking up almost all of that wait time as I have tested many times with everything cached, and when it is not, the UI is not locked while the webassembly app is being downloaded, only when startup of the runtime is initiated.

@mattgenious If you haven't already, I think you should open a separate issue for this so that we can investigate your specific startup performance issue.

Will do, I apologize for causing this much noise, that wasn't my intention.

Will do, I apologize for causing this much noise, that wasn't my intention.

No problem at all! Your startup performance problems sound significant, so I want to make sure they don't get lost in this issue.

We announced .NET 7 Preview 1 today, along with our planned roadmap for ASP.NET Core and Blazor. Support for multithreading in Blazor WebAssembly is planned for .NET 7. Plans can still change, so we'll see how it goes.