Please provide a link, or stop passing speculation off as truth.

Tweets from Google employees who work on chrome:

https://twitter.com/estark37/status/1422694855390629893

https://twitter.com/domenic/status/1422647331804037120

https://twitter.com/domenic/status/1422647483944034308

https://twitter.com/domenic/status/1422704005453582337

Those links contradict your assertion, instead indicating a move to "non-blocking alert()"

From those links:

> Yeah, I think the most likely eventual "removal" path is actually non-blocking alert(). (confirm() and prompt() cannot be converted to non-blocking though, so they'd have to be fully removed)

Blocking Javascript execution is a fundamental part of the `alert` spec. Replacing it with a different, non-JS-blocking thing that happens to share the same name doesn't mean that `alert` wouldn't be removed as it exists today.

And there's just no way at all to make `prompt`/`confirm` non-blocking, they have to block the main JS thread in order to keep the same API.

That breaks the web by definition. There is no way to implement a non-blocking alert(), confirm(), or prompt() in a way that doesn't break existing code that uses them, and that's a lot of code, a lot of the web.

It can block JavaScript execution on the page for compatibility with existing code, while leaving normal browsing unaffected otherwise.

the alert(), confirm(), and prompt() themselves interrupt normal browsing, so I'm not sure what you mean here. They're synchronous so block the main thread, but they also block other user interactions until they're dismissed, so what would be the benefit in leaving normal browsing unaffected if the user cannot browse anyway?