It’s important to clarify which model you’re working with when discussing Blazor. A lot of complaints seem to stem from using the Blazor server websocket model outside of its specific use cases. The web assembly and prerendered models are more comparable to modern developments in other ecosystems.
> I’d never use C# for web dev if I weren’t forced to
.NET Web API is where it's at. I built an Express backend today and it feels primitive. The new minimal templates Web API templates are really good and even easier to get rolling than Express.You get the power of Types with the flexibility of Express (as well as access to the entire node ecosystem), I like it.
It performs almost an order of magnitude worse than ASP.NET Core and isn't any simpler (TechEmpower; considering only the EF + PG non-middleware cases).
I feel like if a team is comfortable with TypeScript and considering Nest.js, C# and .NET Core Web APIs are not any harder, but you get much better throughput for your compute spend.
Could you explain your perspective on Blazor?
...which basically restricts Blazor's use to corporate LAN environments, kiosk applications, and (maybe) PWAs - but it's otherwise completely unsuitable for use on the wider public Internet.
...but we know it'll end-up being used on the public web eventually anyway because developer time is worth more than the end user UX.
The far more common use-case is Blazor server-side which doesn't have this huge download overhead and works like server-side rendering in e.g. React, the download is approximately 150kb.
Isn't it like 1 second of scrolling through Instagram?
The reason being native browser support for JS and nothing else. Java assumes a powerful runtime and c# much less so. WASM is a godsend for interoperability in the browser and I personally hope it delivers us from the curre scourge in the long run.