Hacker News Reader

Comment by teewuane | Hacker News Reader

Wait, why are alert, prompt, and confirm being deprecated? So we are going to need to write poly fills for old features?

View on HN

https://github.com/whatwg/html/issues/2894

Apparently they are. How disappointing, I really like how useful they are for quickly getting something working and maintaining a consistent and expected experience for the user.

Where in that thread are they agreeing to deprecate it? This was someone random asking to deprecate, with the person in charge saying the usage is too high...

I also don't agree with deprecating this without a feasible alternative to ask the user of a page something with a simple line, that works well on desktop and mobile without any extra CSS needed to make it mobile friendly.

The original proposal of the author of that issue is to use NotificationAPI but that is not supported in IE. And a lot of web apps in B2B are extensively using alert and confirm.

I feel this is a solution for websites abusing this feature that will cause a lot of maintenance effort spent in a lot of legit applications.

Here is a better alternative (of course with a lot of drawbacks that I cannot think now in 5 minutes): make the dialog timeout after a period by default. When timing out the dialog disappears without any action/change happening in the rendered page.

These are all terrible from a UX perspective. What in the world were you doing that couldn’t be solved in a more user friendly fashion?

That is a very broad statement. What specifically do you find terrible?

Here is a list of issues I often have with JS-based alternatives that do not exist with alert/confirm/onbeforeunload:

  - the escape key does not close the modal
  - tab focus is not restricted to the modal
  - the modal is not properly announced by screen readers
  - the positions of confirm and cancel buttons differ across sites, leading to misclicks
  - the modal is not or very hard to use on mobile

Building good modal dialogs is hard and much easier done in the browser than on the page. Even <dialog> (if it ever becomes a reality) will not solve all of these issues reliably.

So in a way I agree with you: there might be more user friendly solutions. But the average alternative that people come up with will be worse, not better.

I use confirm() on occasion as a "are you sure you want to delete this?" type protection against misclicks that doesn't involve coding a modal or something.

Same, there's probably hundreds of thousands of business back-end applications that use confirm, as shiny buttons aren't a requirement.

Will they just remove the API (so a JS error) or will it default to "no"?

How cares? I mean, sure if you want to do a shiny applications for consumers, you care. But 99% of the business software doesn't care and wants something that just works.

I use alert, confirm and prompt a lot because it's the simpler way to notify the user, ask for confirmation or ask some input that just works, in all browsers, with vanilla JavaScript, without having to code any CSS (that I hate), or including huge frameworks.

They are used extensively in all enterprise software, where you don't need to be fancy but need to produce something that works reliably.

Removing them to me is a terrible idea. More terrible if there are not alternatives to these, yes there is the dialog API that is supported only by Chrome, and it's not as simple as the good old alert, prompt or confirm functions. And we know that in the enterprise world we would have to wait years to have all the browsers compatible with new APIs, there are still a ton of people that uses Internet Explorer...

By the way this is a so big breaking change that to me would require a new version of HTML entirely. To the point where the browsers if they encounter a old HTML document they keep the old behavior. But they removed the DTD with HTML5 leaving just <!doctype html> that to me was a terrible idea.

Isn't the better solution for the browsers to collectively improve them in that case rather than ditch them & every site roll their own (with custom styles and the over-the-wire weight of the code to implement it)

In your opinion, what's terrible about these from a UX perspective? Is it just the styling or something else?

The alternative to a default confirm prompt is going to be someone including Bootbox in their site, which I'm not sure how that's much better

A single line of code

These functions are blocking, so they can't be polyfilled.

Surely it can be done with a `while (!userHasConfirmed) {}` loop.

Edit: I’m mistaken because now it also blocks the event that would be able to toggle the while condition.

Yet another reason it's bad for asynchronous functions to be a separate type from normal functions.

What do you mean? Do you think all functions should be asynchronous? Do you think no functions should be asynchronous?

Ideally, all functions should be async-transparent. That is, it should be up to the caller to decide how to invoke it. This is usually done with some form of green threading.

It all works great, right up until the moment you have to interop with another language/runtime that doesn't understand your bespoke async. Callbacks (and layers over them such as tasks/promises) are uglier and necessitate opt-in async, but you can interop them to anything that speaks the C ABI.

Green threading is multithreading right? Isn't Javascript singlethreaded? I would assume adding multithreading would break tons of code that relies on it running singlethreaded.

It would break the same as sprinkling "await" all around your codebase. Asynchrony in general is not free - you have to redesign around it regardless, and deal with the issues it introduces.

Callbacks have been in Javascript since the beginning, and await is basically syntactic sugar for that.

Having everything switch to blocking and have to start using mutexes and other multithreading primitives would be a giant change to the language.

Callbacks have been there, but most code wasn't written with that in mind. And you still need some synchronization in async code - even if it's all scheduled on a single thread - due to re-entrancy issues.

All javascript functions should be asynchronous-capable, in a way that's invisible unless you actually touch asynchronous features.

Reply on news.ycombinator.com