I don't see what's astonishing about it and I'm scratching my head asking the same question. If the answer is that you handle disconnections and reconnections the same way that the HTTP protocol does it, then what's the purpose of HTML over web sockets?

You basically end up with a half-assed, buggy, and potentially insecure reimplementation of HTTP running over web sockets running over HTTP at that point.

Are you going to do session management and identification by issuing a unique identifier as well? Is that unique identifier going to be valid in perpetuity or have a an expiry date? Is it going to be valid and secure across all sub-domains or will it be prone to cross site scripting attacks?

>I don't see what's astonishing about it and I'm scratching my head asking the same question. If the answer is that you handle disconnections and reconnections the same way that the HTTP protocol does it, then what's the purpose of HTML over web sockets?

The purpose is in the things explained well in TFA: single source of truth, no replicated state, simpler development, and so on...

Who said the purpose would/had to be in handing "the server caught fire" scenarios?

The purpose is to render your page the "old way" but having the dom updated like an SPA.

It works for certain things and not for others. So, it's not "the future of web software" like the title says, it's one additional possibility for when it makes sense.

> then what's the purpose of HTML over web sockets?

Because you can do things stateless HTML alone cannot do.

No one is trying to re-implement HTTP, or even remove it from the equation.

What people are trying to reimplement (or rather, replace) is the HTML + JSON:API + React + Redux mess. Websockets is a means to that end.

Hm... great intentions, but you don’t seem to have actually answered any of the questions from the parent comment.

Unfortunately, great intentions alone won’t make this work; someone has to actually answer the hard questions about how it’s going to work too.

All the answers I’ve seen so far trying to answer them have been vague hand waving...

That doesn’t leave me with much confidence.

>Unfortunately, great intentions alone won’t make this work; someone has to actually answer the hard questions about how it’s going to work too.

People did better than that, they already built applications with this model.

You are welcome to actually look at the code for any of these solutions.

Here is the documentation for Phoenix channel authentication (what Phoenix Live View is built upon): https://hexdocs.pm/phoenix/channels.html#using-token-authent...

Additionally, here is some documentation on the security considerations specific to Live View: https://hexdocs.pm/phoenix_live_view/security-model.html

Searching can probably find you more information.