Google is considering removing alert()(twitter.com) |
Google is considering removing alert()(twitter.com) |
> as a developer it's good practice to test against early release channels of major browsers to learn about any compatibility issues upfront
This is a rather alarming viewpoint which I think highlights Chrome's quest to become the One True Implementation of web standards. In addition to the major browser vendors I'm now supposed to be testing against beta and nightly builds in order to ensure that my website is not going to break because Google decided to eliminate something? Yikes.
This assumption that behind every website is a team of developers maintaining it for its entire lifecycle is a stubborn and elitist Google fantasy.
On the other hand, I'm seriously worried that Google is using its position to force large changes to the web.
Heck, if they did that it might come back into style. Pop-up notifications are a pain to implement from scratch
event loop, but the _whole point_ of Alert is being MODAL and BLOCKING. If I didnt care about that I would just pop fixed position div. Its meant to pause whole page, thats its designed role.
I seem to remember browsers (Netscape or Opera?) around 1999 having "Never show this dialog again" checkboxes meant to prevent alert() spam.
https://twitter.com/estark37/status/1422694845076762629?s=21
Everything else is speculation. It may even be likely speculation! But it is speculation nonetheless.
It is not speculation to say "Google is considering removing alert()". Multiple engineers from Chrome have confirmed on Twitter that they have an eventual goal of removing alert() at some point in the future (or making it non-blocking and removing prompt/confirm, which is the same thing). See https://twitr.gq/domenic/status/1422647331804037120 as one example.
Maybe it won't happen! There's a lot of time for feedback. But it is accurate to say that Google is considering it.
Also as a small sidenote, they are not considering removing alert() for cross-origin iframes. They are removing it for cross-origin iframes and have very temporarily walked the changes back in order to give devs more time to prepare. Short of some kind of massive blowback that forces the devs to change their mind, Chrome's decision to remove alert() from cross-origin iframes has already been finalized.
I still don't even fully understand the problem, because everyone just defaults to linking a bug tracker that's of lower quality than a Reddit discussion, and I can't trust HN comments to explain it because of all the outrage and assumption-by-framing. Ugh.
Yet..."arrogance precedes the fall".
One day they will pay the price for their carelessness and harm, and I welcome that day.
https://twitter.com/estark37/status/1422694855390629893
https://twitter.com/domenic/status/1422647331804037120
> 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.
i don't think it's about visual design. Having a signalling mechanism that lives outside of the dom is confusing to users, and alert is a rare exception from wayyyy back when. It looks like google is doing this for user security, and I support it.
I don't support the way they're going about it. If Mozilla and Microsoft and W3C are willing to get on board, I would greatly support it. But this is more throwing their weight around, and it sucks!
>existing web
i'm gonna be honest, i havent seen a meaningful alert be used in recent memory, and i work with a lot of web apps. All alert()s could be easily replaced with something inline. I'm not a huge fan of breaking changes, but this is one (with a multi year rollout) that I would support.
I see them used very often to indicate unsaved changes when a user leaves a page.
Calls to alert(), confirm() and prompt() cannot be polyfilled or safely replaced in the general case because they explicitly block the main thread. That behaviour might not be desirable, but it was the path chosen when the relevant code was written. While some maintained applications will be able to switch to asynchronous alternatives, many older and unmaintained websites - the long tail of the web, will stop working.
Now if you wander down the wrong internet 'alley' you'll get mugged by someone using alert() to almost completely hijack your normal session. Especially for older folks (my grandpa really suffered from this), it becomes impossible - to the point they'll even call someone up and give them their credit card number sometimes so they can 'get to their email'.
Warnings to the dev console won't stop this type of harassment of users - only stopping it from being the modal dialog it is supposed to be (per alert() prior behavior) will.
"Protecting the users" is an absolute lie.
I'm actually not a huge fan of the design of confirm() either, but at least that has a valid, modern use
https://github.com/whatwg/html/issues/6897#issuecomment-8857...