One of the earliest projects I took over from a higher level developer was an auction website back around 1998. The site worked like eBay in as far as you could put a maximum bid, and it would automatically bid higher than the last bid up to that point. The problem was, it was all dependent on users being on that page so that the auto-reload http header would fire again and refresh the page. If nobody was on the site watching the auction, no automatic bids would happen and nobody would be declared the winner.

The number of "web cron" things in tools like Wordpress and friends is insane; I've been bit a number of times by this - if nobody hit the site for a day, none of the crons would fire.

Big website, no problem. Small internet site, big problem.

(Yes, for some cron + wget/curl was whipped out)

People often forget that you have to poll to handle lost network connections, IP changes, etc., so there isn't always a real-world win to web sockets.

How about reconnecting the websocket from the client?

Sounds like polling. On an inactive connection, whatever it is, you have to always be polling to see if the connection is still alive.

What do you mean? The client knows when the websocket connection goes down and just reconnects. How is this polling?

Because it always needs some sort of keep alive, which is many times hidden inside the client/web framework

But isn't a keep alive bit better than a "full" polling?