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.
(Source: I have one deployed as a SaaS app)
It usually sounds easy to implement, but comes with more edge cases than you'd expect.
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.
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).
This sort of architecture for static rendering is a big deal because it gives live page updates in a way that is SEO friendly and significantly less complex for development than SPAs are.
There are also many "partial" update mechanisms from XHR/fetch + innerHTML to slim frameworks like AlpineJS/HTMX to newer SSR live rendering like Blazor/LiveView/Hotwire.
Not always the case and in many cases, server side rendering is totally fine and has been for decades. We need to stop suggesting that only 1 solution is correct. SPAs have a place but plenty of use cases can do fine with old school server side renders.
I think SPA were cool and with all the frameworks, it became even cooler to just do more client side work BUT don't forget that there are plenty of studies now that have shown that SPAs are not always the correct and magical answer and in many cases they are actually slower.
this is not true, and if the collective "full stack" community believes this, I feel like I suddenly have a very good understanding of why websites, and more generally the web tech stack itself, sucks so much these days.