The nice thing about persistent connections is that you know when they’ve been closed so you could literally signal that the connection was going down for a deployment and close everyone’s connection. Clients can retry the connection until it comes back up or use another service to monitor the status.

Games basically do this routinely.

But you can do that sort of communication already with existing websockets, without trying to add the complexity of pushing all your regular traffic over that link.

Well, this problem exists at the moment. To be honest sockets is one approach to fix it.

What happens if a webpage is loaded over plain old HTTP and then over lunch a breaking change is deployed. The page the user loaded before lunch is now no longer compatible.

Compatible with what?

It’s stateless. If the api changes from underneath and you’re polling or something, then just show an error, have the user refresh the page and move on. Or use any of the various api version mechanisms for backward compatibility. It’s not an easy problem but it’s a fairly well understood and managed one. Solving this kind of known problem isn’t, to me, a very compelling case for HTML over sockets.

I bet your ass that at least half of the developers reading HN don’t have caching of JS fully figured out such that when the JS changes server-side and immediately needs reloading on the client side that it does then and there instead of on the next request, the next page refresh, or never because they’ve f’d it up.

With server-fed, event-driven pages, you could potentially force refresh.

I leave the browser waiting for a fetch-response from the server. The server responds only later when the page that is open in the browser was updated on server. Seems to work much of the time, but sometimes it seems Chrome closes the connection after a timeout and shows a network error in the dev-tools. FireFox not.

I assume web-sockets could make it work more robustly.

my solution to version changes in a rest api is to sent a version header with every response, the app checks it and if it does not match reloads the page, thus loading the new js.

I would not accept your wager. That being said if this was a “really big problem” I’d bet you that most developers on HN would have an idea how to address it.

it is called hot-reload.