Well this is what happen's when you add plus before prompt, i.e. as below,

Eg :- 1

var a = prompt("Please enter a number");
console.log(a);
typeof(a);

Now in eg (1) when you enter a number and if you check that in console, it show a number but as that number is in-between double-quote, so in JavaScript it's a string, that's what it will show in typeof too when you console that.

Eg :- 2

var a = +prompt("Please enter a number");
console.log(a);
typeof(a);

Now when you console the var a and typeof a of eg(2) the result differs as we have added + before prompt. So this time we get our prompt input value as number and not string. Try you will understand what I'm saying.

Just assign the function call to a variable and don't forget to perform answer checks

var answer = prompt("What is your favorite animal?");
if (answer != null && answer.length !== 0) {
   // do your stuff here
   alert(answer);
}

1. UX: message boxes are mostly evil

Alert boxes are bad in all cases from the UX point of view. In desktop apps. In web apps as alerts or inline JavaScript messages. Everywhere.

You can read About Face 3 by Alan Cooper¹ if you want to know why; it explains very well how does this interrupt the workflow and annoys the user, and how nearly every alert box which exists in current software is deeply wrong. On page 542, "The dialog that cried “Wolf!”" explains that alert boxes are dismissed routinely, so their model is completely broken. On page 543 of the book are listed three major design principles:

• Do, don't ask.
• Make all actions reversible.
• Provide modeless feedback to help users avoid mistakes.

Then, the authors tell us how to replace the alert boxes by the correct design approach.

Prompt messages are slightly different. And still, they break the user experience of your app. If you want the user to enter something, consider using a textbox or a textarea, decorating it with JavaScript when need. Don't be lazy, provide a rich interface in an era of RIA and AJAX-enabled apps; in all cases, if JavaScript is disabled, your prompt will not be displayed.

In web pages, both alert boxes and prompts are mostly annoying. Some examples:

1. Some forums let you create lists by prompting infinitely for the list items. It means that while creating the list, you cannot use the page itself, including copy-paste. You also have a single tiny field. What about long text? What about bold and italics?

2. "If you continue, the photo will be removed definitively from your profile. Are you sure?". Of course I am sure! Would I click "Remove photo from my profile" otherwise? Why your web app supposing I'm so stupid? Actually, Google applications as GMail show the correct approach. You can remove, delete, destroy whatever you want, and when you do so, the app displays a small "Undo" link.

3. "Do you want to take our greatest survey?". Well, actually I was there to visit your website, but since you bother me with your annoying messages, I would rather go somewhere else.

4. "The right click is disabled on this website in order to protect copyrighted photos". Well, actually I right-clicked to change the language of spell checker before sending my comment. Sure, I'll send it without checking the spelling.

Conclusion: from user experience point of view, the applications use message boxes wrongly most of the time.

But wait! Many low-quality websites replace annoying alert boxes by annoying JQuery messages with a semi-transparent background which covers all the page. So the drawbacks remain.

Well, there are another reasons not to use message boxes in web applications :

2. Design: alert boxes have their own design

You can't design an alert box at all. You can't change its color, its size, its font. This makes it even more annoying for the user: you were working with a web app, and your workflow is broken by a message which seems to come from nowhere and does not even match the visual aspect of the app. Not counting that the language of the buttons also match the OS/browser language, not the web application one.

For designers, JavaScript messages are much more powerful than the alert boxes.

They are also much more extensive. You can add bold and italic, you can choose your own buttons (what about: "We apologize but the password you entered is invalid. [Reset my password] [Try another one] [Cancel]"?)².

3. JavaScript: application flow stops

When displaying an alert box, JavaScript stops executing until the user clicks. On a website, it might be ok. With a web app, it often becomes a problem.

4. Sandbox: don't force the user to reboot his computer

Remember the crappy websites which show you an infinite number of message boxes? The only way for the users without enough technical background to be able to continue working was in fact to reboot their computer. This brings us to a problem: alert boxes are out of the scope of the website or web application. You are not authorized to prevent the user from accessing other tabs of the browser³.

The same problem forced the browsers to solve it in different ways. Firefox, for example, permits the access to other tabs when displaying an alert on your tab. Chrome, on the other hand, allows you to check that you don't want to get any alert boxes from a page any-longer, but still blocks the access to other tabs.

While Firefox approach is perfectly valid, Chrome's one can be criticized (since it still blocks every tab), and causes a problem: what if the user was severely annoyed by several message boxes issued by your app and checked the case, and then, you tried to show something really important? Right, the user will never see it.

The fact remains the same, most users will be annoyed by alert boxes, so they are still not very user friendly, and may severely block a user with no enough technical background. Inline, JavaScript messages may block the page, but not the browser itself. Since web app model is a sort of sandboxing, where you can't for example access the user keyboard or reboot the computer or read files from hard disk or go full-screen or use two monitors, alert boxes with their blocking effect break severely this sandboxing model.

Last but not least, what if the user was on another tab when your application decided to show the alert box? What if the user was doing something important, and does not want to interact with your app right now?

^{¹ About Face 3, The Essentials of Interaction Design, Alan Cooper, Robert Reimann and David Cronin, ISBN 978-0-470-08411-3; Chapter 25: Errors, Alerts, and Confirmations.}

^{² This is just an example. Please, don't do it in your web applications, since it's really a poor design choice.}

^{³ If you want a comparison with the world of desktop apps, an inline JavaScript message is like a message box of a desktop application. An alert box in a browser, on the other hand, is like a window appearing from nowhere, set as topmost, on a full-screen opaque background which blocks you from accessing any other desktop application. Any app which will decide to do it once on my computer will be removed immediately, and forever.}