Surely if you want to reliably do some action when a user leaves your page then some persistent connection which dies is by far the most reliable option...?

I'm no frontend expert but cant you just open a websocket and when the websocket dies from the server's perspective, you have your cue to do whatever cleanup you wanted to do?

I also agree with the others here that there shouldn't really be a _need_ for this kind of feature.

Keeping a websocket alive would work, but then you're stuck holding a websocket for all of your users for the full session. Fine if you need a socket anyway, pretty wasteful if you don't. Sockets are pretty cheap these days, but I wouldn't really give this serious thought for a page with a lot of users.

> I'm no frontend expert but cant you just open a websocket and when the websocket dies from the server's perspective, you have your cue to do whatever cleanup you wanted to do?

If I'm not mistaken, and I very well might be, it's kind of the same, however a WS connection here may be less reliable, infact if the user has a spotty connection, when you think "That user left", in the case of a local cleanup, okay that could run on the client side, however this beacon seems to be aimed at sending data back to the server when you leave, in the case of a dropped connection, you wont be able to send the data back anyway to the server.

For this 'browser' based implementation under the hood, the browser *should* have more insight into the real intention of the users exit.

You're right that a persistent connection is the most reliable option. But it's also significantly more difficult to scale and will cause battery drain on mobile devices. The Beacon API is a better alternative for not-entirely-essential cases like analytics.