What makes me most skeptical about Blazor though, is that it's shifting a huge burden to the client just to make developers happy. Even if the runtime is stripped down and compiled to wasm, it seems kinda wild to send a whole runtime just so you can run C# code, especially when there's alternatives like Rust that require no runtime.
What's funnier too, is that it's been possible to write F# on the frontend for a while now, compiling down to javascript (like clojurescript). It makes me wonder why this approach was never done with C# too, even if there are pitfalls in compiling to javascript.
> What's funnier too, is that it's been possible to write F# on the frontend for a while now, compiling down to javascript (like clojurescript). It makes me wonder why this approach was never done with C# too, even if there are pitfalls in compiling to javascript.
There have been several initiatives which allowed you to do that. None of them really successful. I've worked with one specifically in the past (can't remember the project's name though), which even had C# types/bindings for Knockout.js.
FWIW, you seem to be talking about Blazor-WASM, but most real-life Blazor usage right now is server-side Blazor which doesn't do any of that.
Assumption or knowledge?
How do you know this?
Hence the famous xckd comic.
I honestly don't see this happening. Beyond the open source arguments, blazor server-side mode is uniquely compelling specifically for organizations like Microsoft where there are thousands (tens of thousands?) of internal business systems that need some way to interact with, but don't necessarily need to serve 4k video traffic to the entire planet.