It in no way shape or form even competes with load speed, first render, etc on those frameworks unless you have an incredibly poorly engineered TradSPA(tm).
But don't take my word for it, here's a near-hello-world James Newton-King put together on the latest recently for serialization testing that takes 8-13s to first contentful paint on a fast connection with low latency, even with brotli compression:
For ref: That's 60s on fast 3g, with a whopping 23mb into cache (literally as much as youtube's landing page).
The other thing to note is that there's typically an ~1s gap between the completion of dotnet.wasm download and the actual page render, so the first render after a massive download is another 800-1000ms.
Our performance budget is application-related downloads need to be < 200ms on a 1mbps connection, and first contentful paint should be shortly after that (500ms).
Server side rendering: I can't share how I feel about "just throw a fleet of servers at it and it gets way faster," on this site. We're doing 1M requests/s with dotnet core apis on an EKS setup with just a few small nodes and an Angular application that meet our perf budget. All I see at build/etc is Blazor, blazor, blazor, but it's not a realistic option for anything at this point in time compared to tech that's already standard in the dotnet community.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It in no way shape or form even competes with load speed, first render, etc on those frameworks unless you have an incredibly poorly engineered TradSPA(tm).
But don't take my word for it, here's a near-hello-world James Newton-King put together on the latest recently for serialization testing that takes 8-13s to first contentful paint on a fast connection with low latency, even with brotli compression:
grpcblazorperf.azurewebsites.net/
For ref: That's 60s on fast 3g, with a whopping 23mb into cache (literally as much as youtube's landing page).
The other thing to note is that there's typically an ~1s gap between the completion of dotnet.wasm download and the actual page render, so the first render after a massive download is another 800-1000ms.
Our performance budget is application-related downloads need to be < 200ms on a 1mbps connection, and first contentful paint should be shortly after that (500ms).
Server side rendering: I can't share how I feel about "just throw a fleet of servers at it and it gets way faster," on this site. We're doing 1M requests/s with dotnet core apis on an EKS setup with just a few small nodes and an Angular application that meet our perf budget. All I see at build/etc is Blazor, blazor, blazor, but it's not a realistic option for anything at this point in time compared to tech that's already standard in the dotnet community.