Live data from Hacker News

Google is considering removing alert()

twitter.com

21–30 of 41 posts

Re: Google is considering removing alert()

#21
post #6

I've rarely seen alert() used in the past few years outside of as a means of harassing users on malware sites (have you ever accidentally clicked on a malicious ad on a mobile phone and struggled to escape the site due to alert() spam blocking interaction? It's terrifying as an end-user). This seems like a more than reasonable decision given an adequate phase-out period.

And what happens when Google makes an unreasonable decision about what should be a part of the web standards and what should not? Who even has the capability of making them reverse course at this point?

Re: Google is considering removing alert()

#22
https://twitter.com/estark37/status/1422694856544059396

> 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.

Re: Google is considering removing alert()

#23

No. They are not. They are considering disabling it for cross-origin alerts from iframes. https://twitter.com/estark37/status/1422694845076762629?s=21 Everything else is speculation. It may even be likely speculation! But it is speculation nonetheless.

Yes they are, and within a few months, Google will continue fucking over the web. They are explicitly saying there will be breakage because "wah wah it's on the main thread". https://twitter.com/estark37/status/1422694855390629893

[deleted]

Re: Google is considering removing alert()

#24
post #8
post #7

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.

They are planning to deprecate them from the platform entirely, this is the first step

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

Re: Google is considering removing alert()

#25
post #8

Earlier quoted context omitted.

They are planning to deprecate them from the platform entirely, this is the first step

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

Re: Google is considering removing alert()

#26
post #25

Earlier quoted context omitted.

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()"

Re: Google is considering removing alert()

#27
post #25

Earlier quoted context omitted.

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()"

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.

Re: Google is considering removing alert()

#28

https://twitter.com/estark37/status/1422694856544059396 > 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 ni…

Contrary to what seems to be Google's belief, most websites are _not_ continuously deployed SPAs with a team of engineers who work on each release. The indifference shown to actual developers here is staggering.

Re: Google is considering removing alert()

#29
post #16

Earlier quoted context omitted.

> can't think of a nice way to visually distinguish it from the browser's chrome 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 willin…

>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. I see them used very often to indicate unsaved changes when a user leaves a page.

that's confirm(). alert() cant block a page close in progress (by design, afaik)

I'm actually not a huge fan of the design of confirm() either, but at least that has a valid, modern use

Re: Google is considering removing alert()

#30
post #27

Earlier quoted context omitted.

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

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.
Post reply on HN