5 ms·

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

vanviegen 5y ago
These functions are blocking, so they can't be polyfilled.
- Dylan16807 5y ago
  Yet another reason it's bad for asynchronous functions to be a separate type from normal functions.
  - Thorrez 5y ago
    What do you mean? Do you think all functions should be asynchronous? Do you think no functions should be asynchronous?
    - int_19h 5y ago
      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.
      - Thorrez 5y ago
        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.
        int_19h 5y ago
        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.
        Thorrez 5y ago
        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.
        int_19h 5y ago
        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.
    - Dylan16807 5y ago
      All javascript functions should be asynchronous-capable, in a way that's invisible unless you actually touch asynchronous features.
- graftak 5y ago
  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.
NegativeLatency 5y ago
https://github.com/whatwg/html/issues/2894 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.
- irrational 5y ago
  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?
  - dangrossman 5y ago
    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.
    - kuroguro 5y ago
      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"?
  - kristopolous 5y ago
    A single line of code
  - ximm 5y ago
    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.

vanviegen 5y ago

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

Dylan16807 5y ago
Yet another reason it's bad for asynchronous functions to be a separate type from normal functions.
- Thorrez 5y ago
  What do you mean? Do you think all functions should be asynchronous? Do you think no functions should be asynchronous?
  - int_19h 5y ago
    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.
    - Thorrez 5y ago
      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.
      - int_19h 5y ago
        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.
        Thorrez 5y ago
        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.
        int_19h 5y ago
        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.
  - Dylan16807 5y ago
    All javascript functions should be asynchronous-capable, in a way that's invisible unless you actually touch asynchronous features.
graftak 5y ago
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.

NegativeLatency 5y ago

https://github.com/whatwg/html/issues/2894 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.

irrational 5y ago
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?
- dangrossman 5y ago
  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.
  - kuroguro 5y ago
    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"?
- kristopolous 5y ago
  A single line of code
- ximm 5y ago
  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.