The JavaScript event loop, in practice

A click handler runs until it returns. While it runs, the browser does not paint and does not process the next click. That fact explains more frozen prototypes than any obscure API.

The event loop is the browser's habit of taking one waiting task (a click, a timer, a completed network response), running it to completion, then painting if the page has changed, then taking the next task. Your handler is one task. If you search an entire game tree in that handler with a tight loop, the table will not update until the search returns. Players will think the page has crashed.

The practical fix for a long search is to do a slice of work, then yield: schedule the next slice with setTimeout(..., 0) or requestAnimationFrame, and paint a status line in between ("searching, depth 3"). The program is then several tasks instead of one. It is slower in raw moves per second and much easier to stop or to watch.

async functions do not change the rule. The code between two await points still runs to completion. An await is a planned yield, not a way to make a heavy loop polite. If there is no await inside the loop, the loop still blocks painting.