This. No reason to say "the server's gone!" when your user's not doing anything in which that matters. Do notify them _before_ trying to execute on a task that requires the server to be up, but that's not the case that was getting described.

> If the connectivity state doesn't matter to the user, why would you show it?

It's due to Live View triggering a visual indicator that the websocket connection isn't available.

It's a combination of CSS and JS. You can turn this off but if you turn it off then you have no way to show an indicator when you do care (such as transitioning between pages or submitting a form).

I don't think LV at the client level can be coded in such a way that it can tell the difference between the server dropping and the user's connection dropping due to their internet being spotty.

So just to your last point, no one can tell the difference between "you, the client, can no longer reach this particular server" and "this server no longer is up". You might be able to tell that it's the user's connection, rather than a netsplit somewhere, with some reasonable degree of confidence (ping the ISP, ping google, etc), but that's a lot of work, still just a percentage chance of being correct, for no real benefit.

To the rest...that's the point, it's just...CSS and JS. You can change it. You can show it or not, based on what the user is doing, or what view they have. Worst case, you can just hide it completely across everything, as you say, which is then no different from an SPA, except where functionality fails when you have no connectivity. Whether that leads to a better or worse user experience is dependent on the dev's handling of those failures.