[jqpabc123]

With server side rendering you have to reload the whole page everytime

Someone must have lied to you or forgot to explain WebSockets.

Before WebSockets existed, some of us would use a hidden background frame to load server rendered code with a simple "onload" script to move it to the forground replacing only the portion that needed updating.

[drKarl]

Maybe someone lied to you... With websockets you have to keep the connection open, so it would be great to build a chat but not so much for a rich web application...

[tailspin2019]

Blazor Server is a pretty good websockets based framework for rich web applications.

(Source: I have one deployed as a SaaS app)

[gkhartman]

I've wanted to try this, but that connection drop issue sounds like a deal killer when serving page data when compared with ajax polling. How does it handle connection failure? I've worked on event based software for desktop/mobile where the best case was to detect the connection drop on the client side then show a "reconnecting" message while it tries to regain it's websocket.

It usually sounds easy to implement, but comes with more edge cases than you'd expect.

[tailspin2019]

Connection drops have not been as big a deal as I would have expected. But Blazor takes care of that for client side detection, automatic reconnecting, and providing hooks for showing a basic "connecting" UI. There's not a lot you have to implement yourself - the websocket transport is largely abstracted away (unless you specifically want to dig around in there).

That said, I've polished off some of the rough edges with some additional handling. For example, if the user is not directly interacting with the app right at that second of a connection drop, I won't immediately show a loading indicator, so there is no visible difference in the app UI (it just looks like everything is still fine). If the connection reconnects before they interact with it again, they'd never even know it dropped, if it doesn't I then show the loading indicator (which appears after a second or two in any case if the connection is taking longer to reconnect).

If you can cope with the slightly different paradigm of an always connected socket, there are huge upsides to using this framework, and the dev loop can be very fast with hot reloading etc.

[manigandham]

Blazor is the UI framework, the underlying connection is actually handled by SignalR which uses several transports from WebSockets (by default) to server-sent events and long-polling.

The Blazor server framework and JS already handle connection drops automatically but you can also add your own logic (like forcing a page refresh if it takes too long).

[mstipetic]

Phoenix LiveView and similar tech would like to join the chat

[manigandham]

Why not? What about a "rich web application" means it shouldn't or can't have a connection open?