[HN Gopher] Google is considering removing alert()
___________________________________________________________________
Google is considering removing alert()
Author : joshdance
Score : 25 points
Date : 2021-08-04 18:11 UTC (4 hours ago)
(HTM) web link (twitter.com)
(TXT) w3m dump (twitter.com)
| floatingatoll wrote:
| We tried this topic yesterday on the FP with a link to a bug
| tracker, and it went quite badly. I wish someone would write and
| post to HN a serious full-length discussion about what's going
| on, with clearly separated "Google's stated intentions as of
| today" from "Reading the tea leaves" from "This is outrageous".
|
| 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.
| torstenvl wrote:
| 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.
| ohgodplsno wrote:
| 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
| torstenvl wrote:
| No. They are not. Speculation is not reality.
| JohnCurran wrote:
| 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.
| victorvation wrote:
| 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.
| fleddr wrote:
| Well said. It's stunning how ignorant Google is about the
| web. The vast majority of the web is old and poorly
| maintained or not maintained at all. It relies on things not
| breaking, web tech being backwards compatible.
|
| This assumption that behind every website is a team of
| developers maintaining it for its entire lifecycle is a
| stubborn and elitist Google fantasy.
| klyrs wrote:
| They're imperious, but never ignorant. A website without a
| team of maintainers is beneath their concern.
| saulr wrote:
| 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.
| phpnode wrote:
| They are planning to deprecate them from the platform entirely,
| this is the first step
| torstenvl wrote:
| Please provide a link, or stop passing speculation off as
| truth.
| phpnode wrote:
| 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
| torstenvl wrote:
| Those links contradict your assertion, instead indicating
| a move to "non-blocking alert()"
| phpnode wrote:
| 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.
| zozbot234 wrote:
| It can block _JavaScript execution on the page_ for
| compatibility with existing code, while leaving normal
| browsing unaffected otherwise.
| phpnode wrote:
| 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?
| Minor49er wrote:
| They're talking about removing alert(), but there's no mention of
| confirm()?
| zaksingh wrote:
| 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.
| nonbirithm wrote:
| 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?
| trangus_1985 wrote:
| Good. Alert is an archaic mechanism with tons of useful
| alternatives that don't involve blocking the DOM. For example,
| console log for debugging/demoing.
|
| On the other hand, I'm seriously worried that Google is using its
| position to force large changes to the web.
| phpnode wrote:
| it's not good, this change will break huge swathes of the web
| if it goes ahead as planned, lots of older websites just won't
| work any more and many newer ones will also be affected.
| trangus_1985 wrote:
| There is no place for an out of dom signalling mechanism like
| alert() on the modern web. I would hope to see a multi-year
| phase out of something this integral. I can't remember the
| last time I saw it used for something useful.
| phpnode wrote:
| deprecation is totally fine, log a warning in the console,
| discourage people from using it, but don't throw the
| existing web under a bus because your UX team can't think
| of a nice way to visually distinguish it from the browser's
| chrome!
| lazide wrote:
| Pretty sure it's a different problem - alert() is a true
| modal dialog that blocks almost all other normal
| interactions and is very disruptive. Back in the day when
| apps weren't constantly gaming all user interactions to
| squeeze on extra ad click out or whatever, it was still
| abused - but rarely.
|
| 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.
| ohgodplsno wrote:
| Every major web browser has implemented a "do not show
| alerts from this site anymore" checkbox that appears
| after 2-3 consecutive alerts.
|
| "Protecting the users" is an absolute lie.
| trangus_1985 wrote:
| > 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 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.
| plopz wrote:
| >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.
| lkschubert8 wrote:
| Isnt that confirm()
| trangus_1985 wrote:
| 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
| phpnode wrote:
| The UX issue is directly highlighted in their rationale
| for the change.
|
| 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.
| MinusGix wrote:
| It isn't uncommon for me to find a site that uses it
| legitimately. Sometimes for telling the user info,
| sometimes for reporting an error, and sometimes for other
| goals. Sure, it'd be better if they did it in a more
| normal manner (writing their message into an HTML
| paragraph), but they do use it. But a lot of these sites
| are dead (though some aren't) and so it for the most part
| doesn't matter if you remove it now or after three years.
| They'll still break or lose functionality. Just spit out
| a warning to the dev console when it is used.
| brundolf wrote:
| A good compromise could be to have it trigger a non-blocking
| pop-up notification within the page, since the blocking is the
| main issue
|
| Heck, if they did that it might come back into style. Pop-up
| notifications are a pain to implement from scratch
___________________________________________________________________
(page generated 2021-08-04 23:03 UTC)