Comment by dfabulich | Hacker News Reader

Comment by dfabulich | Hacker News Reader

Parent Full thread

I think it's even worse than that, because by being "webby" here Deno has committed itself to alert(); multiple browser vendors (including Mozilla) have advocated removing alert() from the web platform.

(They want to do that because alert() "stops the world" by blocking the main thread event loop, and because they make it easy for a site to post a message that appears to come from Chrome itself, or from another website.)

https://groups.google.com/a/chromium.org/g/blink-dev/c/hTOXi...

> We’re on a long, slow path to deprecate and remove window.alert/confirm/prompt and beforeunload handlers due to their role in user-hostile event loop pausing, as well as phishing and other abuse mechanisms. We’ve been successfully chipping away at them in various cases, e.g. background tabs, subframes with no user interaction, and now cross-origin subframes. Each step is hard-fought progress toward the eventual goal, and we should consider carefully whether we want to regress, even in an opt-in manner.

Rich Harris has a good blog post about this. https://dev.to/richharris/stay-alert-d

Removing alert is nonsense, and I don't think they will ever do (without breaking a ton of websites that use it). Why as a developer should I have to make a modal with HTML+CSS+JS to show it to just have a prompt that inform the user about something?

Ok, alert is ugly, but for a lot of situations (= industrial software) it's perfectly acceptable.

Why as a user should I have to endure a website with an intrusive user of alert? I don't care what happens to websites that use alert, I never want to see my browser get locked up because of lazy devs wanting to use alerts.

Alerts haven't locked up the browser since the Bush administration.

Frrl free to update https://stackoverflow.com/questions/8825384/alert-is-bad-rea... with new information.

That question has been closed and locked since Obama's first term

That only because the implementation is poor. It doesn’t have to be intrusive.

Sort of. This can obviously be non-blocking and redirected to whatever stdin-ish receiver you prefer:

  alert('whatever');

This cannot:

  const answer = confirm('A querstion?');
  const value = doSomethingWithUserInput(answer);
  return doSomethingWithValue(value);

The API depends on it blocking the main thread, and removing that expectation is effectively just as disruptive as removing the feature entirely: non-abusive usage would have no reason to call this function if not to block for user input. Introducing some magical suspension of the stack like async/await or generators would break assumptions about the entire concurrent execution model of the language (the inverse problem of “colored functions”, infectious async/await etc).

The best thing they can do without removing the API is provide an escape hatch, which most browsers already do when alert &co are called multiple times in quick succession.

Alert doesn't lock your browser. The developer can spend a lot of time and effort to make an even more intrusive and annoying custom alert.

Why should I as a user have to endure instagram and twitter blocking content with a delayed login prompt that cannot be canceled? Because they can. Browser APIs or not malicious developers will be malicious.

Yes it does. You can't click on the URL bar and just navigate to a different site in chrome while an alert is displayed.

I can.

You can in firefox (just tried from the console).

Some devs want to use the native UI, but this isn’t okay either apparently. So are you advocating that every dev should implement their own alert modal?

Browsers are well equipped to deal with alert() abuse. You can usually block them after the second one.

>beforeunload handlers ooh no, how will sites tell me that my free offer will expire if I navigate away?

But on the serious side, this is useful for many antiquated apps (e.g. government stuff) that break tons of stuff if you attempt to re-submit a form, use the back button, etc, so I see that causing a ton of problems.

Yes. I work on applications that run for a long time in the browser with many subframes. The beforeunload event helps us clean up things and manage our applications' states better.

Yeah, especially after having had it for years, business leaders just do not understand why the browser would remove such a useful feature. And then you get questions like “So? Can we just stick with IE 10 then?”

I still haven’t found a way to consistently send a request while the tab/browser is closing.

visibilitychange and sendBeacon

Why would you need it to be consistent? Depending on this for anything other than analytics is bad design. It’s like catching sigterm on desktop.

Rich Harris actually disagrees with the browser vendors decision to deprecate alerts. From the article you linked:

> We can't normalise the attitude that collateral damage is the price of progress, even if we accept the premise — which I don't — that removing APIs like alert represents progress. For all its flaws, the web is generally agreed to be a stable platform, where investments made today will stand the test of time. A world in which websites are treated as inherently transient objects, where APIs we commonly rely on today could be cast aside as unwanted baggage by tomorrow's spec wranglers, is a world in which the web has already lost.

Reply on news.ycombinator.com