I believe this tweet has been twisted from the original tweet, which is that _cross origin_ alert (e.g. from an iframe) is the thing being removed. Using alert etc from the main frame will continue to work.
> 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.
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?
