5 ms·

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 advocat

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/hTOXiBj3D6A/m/JtkdpDd1BAAJ 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 https://dev.to/richharris/stay-alert-d

seanp2k2 5y ago
>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.
- michaelgrafl 5y ago
  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.
- Aeolun 5y ago
  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.
  - NavinF 5y ago
    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.
alerighi 5y ago
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.
- antifa 5y ago
  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.
  - ______-_-______ 5y ago
    Alerts haven't locked up the browser since the Bush administration.
    - antifa 5y ago
      Frrl free to update https://stackoverflow.com/questions/8825384/alert-is-bad-really https://stackoverflow.com/questions/8825384/alert-is-bad-rea... with new information.
      - ______-_-______ 5y ago
        That question has been closed and locked since Obama's first term
  - aidos 5y ago
    That only because the implementation is poor. It doesn’t have to be intrusive.
    - eyelidlessness 5y ago
      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.
hitekker 5y ago
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.

seanp2k2 5y ago

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

michaelgrafl 5y ago
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.
Aeolun 5y ago
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.
- NavinF 5y ago
  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.

alerighi 5y ago

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.

antifa 5y ago
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.
- ______-_-______ 5y ago
  Alerts haven't locked up the browser since the Bush administration.
  - antifa 5y ago
    Frrl free to update https://stackoverflow.com/questions/8825384/alert-is-bad-really https://stackoverflow.com/questions/8825384/alert-is-bad-rea... with new information.
    - ______-_-______ 5y ago
      That question has been closed and locked since Obama's first term
- aidos 5y ago
  That only because the implementation is poor. It doesn’t have to be intrusive.
  - eyelidlessness 5y ago
    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.

hitekker 5y ago

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.