* The payload of WASM makes it a difficult choice if serving mobile or regions with poor internet and you want a good first impression.

* Server side needing a constant socket for everything presents it's own limitations.

* It has hot reloading, but it pales in comparison to the JS experience at best and in my own experience has a lot of edge cases leading to full rebuilds.

* C# tooling is fantastic; Razor however I've found to be slow and well behind the experience of popular JS libraries.

* When you do need JS interop (e.g. browser API's) the experience is, IMO, awful.

I feel Blazor's niche is internal, simple LOB apps and I can understand the appeal if you don't already know JS or have some serious regulatory requirements around vendors and need to avoid NPM.

Personally, I find the DX and quality of the end product in svelte kit trump the code sharing of Blazor.

Last time I looked at Blazor it only had two options, which were both equally horrible for public websites.

You either had to ship a big and bloated WASM file, which was at least 10x the size of competing JS frameworks, and in some cases 100X the size. Or you had to render all dynamic parts of your website on the server, which made latency a huge problem, since your website feels sluggish between each interaction.

I don't know when it was the last time you took a look at Blazor, but Blazer server is extremely fast. I built some big corporate apps with it and never had any latency problems.

Were they internal or external apps? Because latency was the problem last time I looked, and it won't be super noticeable if you have the servers that close to you.

Because last time I looked, the Blazor binaries were huge, and had performance issues?

It's also irrevocably attached to that specific dotnet framework? Want to evolve parts of your stack? Too bad.

Blazor is a non-starter if you care about payload size and startup time. Fine for intranets but not much else.