Cédric BelinUnpopular opinion?
Blazor WASM is just a mistake: too heavy, too slow.
I would have preferred Microsoft to do with C# what Google did with Dart: compile the code directly into JavaScript.
Miha Markič
@mihamarkic Hmmm....
"Currenly, the only supported target is WebAssembly. Other targets may be enabled in the future, but we are not investing work into them at present."
A little too early 😅
@cedx Well, it compiles to WASM which is at least decent fast and most probably faster than JS. Also C# can't be compiled to js without severe limitations while with wasm there are less limitations.
@mihamarkic A FrontEnd application essentially does DOM manipulation and event handling.
**At present**, WASM is not at all suited to this type of use. WASM was created for heavy calculations.
That's why JS is faster for a typical FrontEnd app.
https://krausest.github.io/js-framework-benchmark/2025/table_chrome_137.0.7151.55.html
(Blazor WASM is about 4 times slower than Lit, for example.)
I do agree, however, that there would probably be major limitations if C# code had to be compiled directly into JS.
@cedx Yeah, if you need DOM manipulation, it's slower today - I'm sure this will change soon though. But you really don't have any other option since no such language would compile to js - dart was built with this in mind and lacks in other features. But at the end of the day, do you really think this DOM WASM manipulation is really that bad for the end user? Perhaps, but OTOH productivity is great and if nothing else, LOB applications are a great target.
@cedx If DOM manipulation perf is that important to you, then you should go with another tool or combine js with C# WASM.
@mihamarkic We investigated in Blazor WASM because sharing code between the backend and the frontend is great, and Razor components are nicer.
We ported the frontend of an app to form a concrete opinion. The feedback from our users was pretty bad: "Have you changed anything? It seems to be slower than before".
And that's what happened: event handlers went from 35ms to 200ms! Enough for users to notice.
The productivity/pleasure of developers is not a good reason to penalize end-users.
2/2
@cedx ha, you shouldn't have spoiled them in the first place. But seriously, ask them if they are willing to pay X more for the product and maintenance in favor of some speed increase. Also, did you try server side blazor?
@mihamarkic "you shouldn't have spoiled them in the first place"
Hahaha 😂 Not wrong.
"ask them if they are willing to pay X more for the product and maintenance"
They don't pay for it: our apps are for internal use, our users are coworkers.
And frankly, they're not being kind to us.
"did you try server side blazor"
No, we haven't had the time yet.
@cedx Ah internal within the company, but still somebody is paying.
But hey, you should really try the server version. The only annoying point is that it loses connection after inactivity and a refresh is required.
"I'm sure this will change soon though." Yes, but unfortunately not yet. We'll probably have to wait a few years before WASM improvements hit our browsers.
"Do you really think this DOM WASM manipulation is really that bad for the end user?" Unfortunately… yes!
At work, we develop mostly Intranet/LOB/SPA applications. Our stack is ASP.NET Core/Minimal APIs for the backend, TypeScript/Lit/WebComponents for the frontend.
1/2
Bragg@cedx stupid question time what does it do? I always assumed the C# was compiled into JavaScript.
Cam@cedx I don't really disagree with you on the performance side, but I'm not sure I want to live in a world where JavaScript is the only answer to web development 😅
@bitflipped I agree. There are a ton of languages that compile to JS (Dart, Haxe, Kotlin, etc.), which is why I think Microsoft could have done better.
@cedx When AOT compilation becomes more mature, with fewer limitations, it will presumably allow more Blazor applications to be compiled to WebAssembly directly, rather than using interpreted bytecode.
It will be interesting to see what effect that has on performance.
@bitflipped There is hope. One avenue currently being explored: the possibility of WASM exploiting the JS garbage collector. This would allow the .NET garbage collector to no longer be shipped.
Igor Stojković@cedx I don't understand. How would translating to Javascript make it smaller and faster? The language heavily depends on its runtime so you would have to translate everything still.
@driggy
"you would have to translate everything still"
That's exactly what Google has done with Dart. And the produced JS is smaller and faster than the WASM produced by Blazor.
(Don't ask me how they managed this feat.)
WASM is **currently** not a good target for DOM manipulation and event handling. And that's most of what a FrontEnd application does.
There are a ton of languages that compile to JS (Dart, Haxe, Kotlin, etc.), which is why I think Microsoft could have done better.
@cedx ChatGPT summarized it like this: C# doesn’t target the JS engine because its runtime model is too complex to map directly, and Microsoft is betting on WebAssembly for performance, compatibility, and simplicity. Dart, by contrast, was built with JS as a first-class output.
@driggy I can only agree.