Yeah, you'd need a lib or roll your own that races the response against a timeout.

Kind of like how you also need to implement app-layer ping/pong over websockets for keepalive even though tcp already sends its own ping/pong. -_-

As for EventSource, I don't remember exactly, something always comes up. That said, you could say the same for websockets since even implementing non-buggy reconn/backaway logic is annoying.

I'll admit, time for me to try the thing you pitch in the article.

I have only small experience programming with web sockets, but I thought the ping pong mechanism is already built into the protocol. Does it have timeout? Does it help at the application layer?

Ref: https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_...

You only need to implement it yourself if you’ve catastrophically fucked up the concurrency model on the client or sever side and they can’t respond out of band of whatever you’re waiting on.

Discord implements its own heartbeat mechanism. I've heard websocket-native ping is somehow unreliable. Maybe in case the websocket connection is fine but something happened at the application layer?

"Unreliable" is a bit harsh - the problem arises imho not from the websocket ping itself, but from the fact that client-side _and_ server-side need to support the ping/pong frames.

The WebSocket browser APIs don't support ping/pong

Native EventSource doesn’t let you set headers ([issue](https://github.com/whatwg/html/issues/2177)), so it’s harder to handle authentication.