Deno: Request: alert, confirm, prompt, and their async counterpart

[KSXGitHub]

Rationale

The browser already provides window.alert, window.confirm, window.prompt. I think it would be nice if Deno supports them too.

Implementation

• window.alert simply prints text to stdout and wait for user to press any key.
• window.confirm asks a yes/no question, waits to for user to respond either "y", "yes", "n", or "no".
• window.prompt asks user to enter a string.
• All the above methods block event loop.
• It would be nice to have their async counterpart as well. But they should belong to Deno namespace.

[ry]

Sounds reasonable...

[kitsonk]

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.

[KSXGitHub]

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

[kitsonk]

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

[KSXGitHub]

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.

[kt3k]

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"?