1D0-635 · Question #58
How is the alert() method different from prompt() and confirm()?
The correct answer is D. The prompt() and confirm() methods return a value, whereas alert() does not. See the full explanation below for the reasoning.
Question
How is the alert() method different from prompt() and confirm()?
Options
- AThe alert() method generates a modal dialog box, which requires user action before the next
- BThe alert() method requires only one parameter, whereas prompt() and confirm() require two
- CThe alert() method requires two parameters, whereas prompt() and confirm() require only one
- DThe prompt() and confirm() methods return a value, whereas alert() does not.
How the community answered
(25 responses)- A4% (1)
- B16% (4)
- C8% (2)
- D72% (18)
Community Discussion
8D is your answer, and here is why it sticks. Think of it this way: alert() is a ONE-WAY STREET. It just says "Hey, look at this!" and gives the user a single OK button to dismiss it. No value comes back to your script, nothing to capture, it is purely a notification. You can remember it with the acronym ALERT = A Loud Empty Return Truck, meaning the truck shows up, dumps its message, and drives away empty-handed. But prompt() and confirm() are TWO-WAY STREETS. prompt() hands you back whatever the user typed in, as a string (or null if they cancel). confirm() hands you back a boolean, true for OK and false for Cancel. Use the hook P and C Give Back, A Does Not, and you will never mix these up on test day. Option A is a trap because ALL THREE methods create modal dialog boxes, that is actually something they share in common, not a difference. Options B and C are just noise about parameter counts, which are not what defines the real behavioral difference here. Lock in D: prompt() and confirm() return values, alert() does not.
The return-value distinction also maps cleanly onto interaction intent, alert handles notification, confirm handles binary decision-gating, and prompt handles lightweight data collection, which connects to Nielsen's user control heuristic because only two of the three actually let the user influence what the script does next.
My first instinct was A, because from a UX perspective the modal behavior of alert() feels like its defining characteristic since it blocks the rest of the interface until the user dismisses it. Then I caught myself, because prompt() and confirm() are also modal and also block interaction in exactly the same way, so that cannot be the distinguishing factor between them. What locked in D for me was thinking about how each method fits into the interaction model. Alert() is a one-way notification, you are just surfacing information to the user and nothing comes back to your script. Prompt() hands you a string from the text field, or null if the user cancels, and confirm() hands you a boolean, true for OK and false for Cancel. Those return values are what allow your code to branch based on what the user did, which is the whole point of using those two methods in a workflow. Option B tripped me up for half a second because prompt() does accept a second parameter as a default value for the text field, but that parameter is optional, so saying prompt() "requires" two is inaccurate. D is clean and correct because the return-value distinction is fundamental, not a quirk of how many arguments you pass in.
I actually got tripped up on this one at first because I kept thinking about how all three pop up a dialog box, so I almost picked A, but then I remembered my senior saying "only alert is a dead end, the other two actually hand something back to your code." Once I thought about it that way, D clicked instantly because prompt gives you back whatever the user typed and confirm gives you true or false, while alert just shows a message and returns undefined.
Love your senior's framing, and I lock it in with APC, Alert is a Postcard you send with no return address, Prompt is a Pickup window where the user hands you a string, and Confirm is a Coin toss that lands on true or false.
D is the one you want, and the reasoning clicks fast once you think about what each method actually does with your input. Alert just throws a message on screen and waits for you to dismiss it, end of story, nothing comes back. Prompt gives you a text field and hands back whatever the user typed, or null if they bailed out. Confirm gives you OK and Cancel and returns true or false accordingly. So prompt and confirm both feed a value back into your script, and alert never does. Option A trips people up because all three methods do produce a modal dialog, so that wording feels true but it is not what separates alert from the other two. B and C are trying to bait you into counting parameters, which is a distraction. On my actual 1D0-635 day I almost went with A because the word modal jumped out at me and I had been drilling dialog behavior all week. Then I slowed down, thought about what a return value means in code, and it landed clean. D it was, moved on, never looked back. If you are shaky on this, just ask yourself what you would assign to a variable from each method. You can write var x = prompt() or var x = confirm() and get something useful. Try that with alert and you get undefined every time, which tells you everything.
D is the right call here. alert() just shows a message and the return value is undefined, it gives you nothing back. prompt() returns whatever the user typed as a string (or null if they hit Cancel), and confirm() returns a boolean, true or false depending on OK or Cancel. That distinction matters a lot when you are writing code that needs to branch on user input, because you can actually do something with the return value from prompt() and confirm(), whereas trying to capture the result of alert() is pointless.
Good catch on the null case too, because my senior showed me that even confirm() comes back null if the user dismisses the dialog without clicking OK or Cancel on some browsers, so checking for null before you branch on the boolean can save you a headache.