Also yeah javascript has labels but using them is usually a bad idea. While they may seem useful they can be harder to reason about in all but the simplest code. You're almost always better off restructuring your code instead of using labels.
If the handler goes missing or fails, this construct will prevent the link from doing what it usually would.
But using a button is better in such cases...
Back then, you'd use it with the `href` attribute to prevent the link from going anywhere (it would return `undefined`), then call a function with the `onclick` attribute.
E.g.
<a href="javascript:void(0)" onclick="clickHandler()">Click me</a> <a href="javascript:void(0)" onclick="dostuff()">Click me</a>
onclick="dostuff()" will then listen for clicks and call the `dostuff` function to update the page or load a new one.
Nowadays it's considered bad practice and to be honest it wasn't exactly good practice in those days but it was very commonly used.
On the other hand, if the event loop's job also includes rendering the game's UI, then leaving it by any means will freeze the display until it's restarted. That's probably bad too, although I suppose in theory it could be turned into a game mechanic. Absent that, this technique might make more sense in a case where you're running the exitable loop in question on a secondary thread (i.e. a worker), and doing things with it which can be safely interrupted - maybe changing levels or something, where the player isn't expecting to do anything during a UI transition, and you need to await the arrival of some resources over the network and then set up the game state before restarting the event loop to resume normal play? I don't know, that's a bit contrived and probably flawed in a critical way, but I think it makes the same basic sense as offloading heavy and necessarily synchronous work to a worker thread does in general.