Hacker News Reader

Comment by manigandham | Hacker News Reader

Pages can be server-side rendered and then hydrated after load, in either mode. This makes a dramatic difference in usable latency.

View on HN

Sure. But it still takes some time until the interactive part works. And it doesn't solve connectivity issues a SPA can easily handle.

SPA = single page application. You can make one entirely in Blazor and can host it on any static file host. Are you talking about Javascript specifically?

The difference of Blazor compared to a "classic" SPA (for example React + JSON API) is:

Blazor Server: On a broken/poor connection there is no interactivity anymore

Blazor WASM (=SPA): Keeps working when connection is lost, but everything is sooo slow

classic SPA: Keeps working with lost connection and is fast.

Last year I created a Blazor WASM app[1] to get familiar with the tech. It was a game based on the board-game from the 60's called "Acquire". Although it's using the WASM hosting model, I did use SignalR to facilitate the real-time game play between players. The "practice" mode against the crude AI is entirely WASM and can be "played" as a PWA completely offline. I had intentions of finishing this out, but I got far enough that I learned what I needed to for now. I felt like it was pretty good considering it's probably less than 40 hours of work and I'm a mobile/desktop dev not a Web dev.

[1] https://acquiregame.azurewebsites.net/

> Blazor WASM (=SPA): Keeps working when connection is lost, but everything is sooo slow

Why should it be slow? Once Blazor WASM is loaded, it doesn't need a connection to the server anymore.

.NET runs in WASM around 20 times slower than in the server runtime. The application is just slow, not the network.

Reply on news.ycombinator.com