The future of web software is HTML over WebSockets

I don't think so but if I'm wrong please correct me.

For example, imagine this simple scenario: you load the comment page for this post on HackerNews

HackerNews renders an HTTP response to your browser and your browser renders the page based on that HTTP payload.

You can be sitting here on the page for 10 minutes reading comments and even if HackerNews randomly went down 20 times for 10 seconds each time during those 10 minutes you would never know because your browser has everything it needed to render the page when it loaded. It's a done deal. The request was made and the response was served.

But now let's say you use LiveView and you made this page an actual Live View. Let's also say you load all of the comments at once to keep the example the same.

Since there's a persistent websocket connection open at all times, in all 20 cases of HackerNews going down you're going to get a visual warning that the websocket connection was dropped. You also don't want to disable this visual warning because on slower devices it might take 2 seconds to load the page which is much different than an uncontrolled disconnect.

IMO this user experience is pretty bad. Why should users be concerned with the server's state after it has everything it needed to handle the request it asked for (loading the comment page). If they try to post a comment and the server is down then the user should see that error at the time of them making the comment (such as a custom 502 error page if the back-end is down).

The grandfather's comment of "it wasn't designed this way by accident" is spot on. The stateless web is a happy web. Sure you can sprinkle in websockets for progressive enhancements like broadcasting new content somewhere (which is awesome when done well), but websockets shouldn't be the basis for everything. HTTP has decades of very careful thought and optimizations around its protocol.

"Modern" experience is not necessarily the same as "good" experience. Good old server side rendered pages are fine; SPAs are being built just because "we can", not because they are actually needed (sure, in some cases,SPAs are needed, e.g., chat sites).

But instead reminds me of a friend who went full gRPC learning, so far as to start contributing to the newer standard definitions of RPC, he used to turn around and say that all API's SHOULD be replaced with gRPC and argue as I would about how its not always needed etc, he knew enough to counter with good reasons instead or the reasons why it should be.. And sometimes thats the biggest hurdle, its not that it can do everything better, even easier. It's just the commitment devs/companies whoever will have to do it..

I'm guilty of not using the right tool for the job sometimes.. But I'm struggling to think of any protocol or implementation that has been fully replaced without huge intervention..

Even TSL/SSL implentations was (rightly) pushed heavily by browsers, no ssl, no sensitive data transfer. But on its own, I don't see any replacements today wiping out the old.

I'm no fan of latest fads.. You show me a good standards doc thats got strict implementations, I'm on board! You show me a 'recommendation' based on some amazing points and valid critique, I'm not so enthusiastic..