[jdmichal]

Examples from TFA:

* Web-based REPL or IDE environments, where the iframe is typically the primary user interaction space.

* Paid third-party website embedded into an internal website.

* Hosted JS content such as Kongregate games.

* Frames wrapping older webapps as part of an evolutionary uplift plan.

[masswerk]

So everybody has to write or to add some kind of UI-kit and use async-await or callbacks. The loss of a blocking state for that particular thread is in practice the only result of this (besides breaking a lot of backward compatibility).

However, the loss of system dialogs in favor for custom UI-kits implemented in the DOM is a major attack on accessibility.

Edit, regarding backward compatibility: A sustainable web-stack is really of major concern. For some decades now, most of human creativity and content production has been published on the Web, much of this exclusively so. Backward compatibility is important, if we don't want to leave a singular black hole as our legacy and as the heritage of future generations. For us as a society, as a culture, this is of much more importance than adding yet another fancy capability to the standard. – As it turns out, the singularity is not artificial superintelligence (ASI), but the evergreen browser and rolling web standards (EGB-RWS).

[stefan_]

Those are not "use cases". What is being blocked here is alert. It's like I need to put "that also calls alert" at the end of every example you put forward.

[donatj]

It's not just alert, it's also confirm which I think it's a perfectly legit popup, and you see it a lot for navigation with unsaved changes.