Sounds reasonable...

My fear is that they could easily become vectors for a DOS attacks, so we would want to put them behind permission flags. They have been abused so much in browsers it lead to the notifications API. I would much rather see us implement the notifications API and move the permissions to the global namespace.

@kitsonk

My fear is that they could easily become vectors for a DOS attacks

What type of attacker you are talking about? I wouldn't allow my server to execute arbitrary code from the user so a malicious user shouldn't be able to call window.alert to block my server.

behind permission flags

I don't think this is necessary either. These window methods only block when stdin is interactive (waiting for user to type in input). If stdin is not interactive (such as pipeline), then these methods shouldn't block execution.

They have been abused so much in browsers it lead to the notifications API

I fail to see any negative in this. It is true that alert in the browser was annoying to the end-user, it is due to the browser's poor implementation of dialog box. But it has changed now, alert on one Chrome tag would no longer affect operation on the other tag.

I would much rather see us implement the notifications API

On Electron and deno_webview, this is a must-have. But Deno is CLI only, it does not aim to provide full-fledged web APIs.

What type of attacker you are talking about? I wouldn't allow my server to execute arbitrary code from the user so a malicious user shouldn't be able to call window.alert to block my server.

But someone calling window.confirm() would. The whole Deno security model is a trust no one model. You wouldn't allow someone to read read from the file system, or connect to the network, but we flag those in Deno.

But Deno is CLI only, it does not aim to provide full-fledged web APIs.

Exactly. A good reason not to implement these.

The reason we implement any of the APIs for the web is to increase code portability. My opinion still is that if you are authoring isomoprhic code, you wouldn't be using these APIs in the browser, so why use them in the CLI?

If you don't like my opinion about them being "bad" APIs, take a look at the desire from those involved in the standards bodies who want to remove them from the web...

https://twitter.com/domenic/status/1242613521382334464?s=20

But someone calling window.confirm() would. The whole Deno security model is a trust no one model. You wouldn't allow someone to read read from the file system, or connect to the network, but we flag those in Deno.

We don't want to allow unknown code to read from the our filesystem because we concern about our own security, not security of our users.

I will try my best to guess your concern: You are worrying that a library that does not use window.confirm before, suddenly add it to their code, causing the server to suddenly stop to ask for input? There are thousands more way to cause similar DoS without ever using window.confirm/window.prompt, there is no security measure against that other than library user's responsibility.

Anyway, if reading from stdin requires permission, then window.confirm should require permission as well.

If you don't like my opinion about them being "bad" APIs, take a look at the desire from those involved in the standards bodies who want to remove them from the web...

https://twitter.com/domenic/status/1242613521382334464?s=20

I don't know how serious should I take a Twitter post. If window.alert is so universally hated, why aren't there any deprecation notice yet? Not in Chrome console, nor in MDN. _{(And why does this issue have 7 upvote emojis?)}

The reason we implement any of the APIs for the web is to increase code portability. My opinion still is that if you are authoring isomoprhic code, you wouldn't be using these APIs in the browser, so why use them in the CLI?

Currently, browser and Deno do not share any API for basic I/O: stdio does not exist in the browser and HTML does not exist in Deno. window.{alert,confirm,prompt} are the only things that both can ever share.

Furthermore, when new developers first learn JavaScript, there's a good chance that they will learn and use window.{alert,confirm,prompt} for basic IO because it is easy.

I think this kind of feature, especially prompt, is very useful for new learners to learn the very first interactive programs in console. This kind of feature is also necessary for Deno to be considered as a "batteries included" runtime. If it needs 3rd party libraries like x/ask or x/prompt for performing such simple input, is it really called "batteries included"?

As you may have heard, there is widespread debate about the deprecation of these methods, which have clear deficiencies - their deprecation was proposed in 2017 and hasn't happened, but there's been pressure from the Chrome team and others to get it moving, and it's sparking a lot of debate online.

As many have pointed out, despite their problems, these methods actually fill a need - I've seen many making the argument that these should not be deprecated before there's an alternative. For example, these are useful for beginners and for prototyping.

This doesn't need to be something big and fancy, just an async (Promise) version of those 3 basic interactions. The biggest issue is probably naming. How do you name these or where do you put them?

Perhaps someone from the Deno team could step in with a proposal? 🙂

@mindplay-dk Async or not, using these methods to interact with users is bad UX. A professional web developer should at least make a <form>. The only values that these methods offer for the web is ease to learn for beginners: It makes interacting with I/O in the web browser similar to what they learned in C++.

Well, of course. I don't think anyone claims it's good UX to use these methods. The web had form elements long before it even had JavaScript, so I don't think this was never intended for primary UI.

But these are useful features for beginners, for quick prototyping, and sometimes for personal/one-off scripts.