Lately I've been developing a web-based management system for a gym. Their previous app was developed in Visual Basic. For the new app, all the front-end scripting uses jQuery, the server is running PHP & MySQL... you know, the typical el-cheapo linux based stack.

Anyways, I was wondering why JavaScript's prompt, confirm and alert message dialogs are so underused nowadays. There a lot of jQuery plugins for modal windows and alert messages that try to mimic something that the language already offers and every browser is forced to support properly.

Using hand-made or plugin-based solutions is ok for complex forms and special needs, but if you just need to ask for a single value or confirm the deletion of a record, why would you add such overhead to your web app? Furthermore, iOS and Android offer nicely adapted message dialogs when you use prompt, confirm and alert.

  • 7
    "El cheapo?" Really? Isn't that a little pejorative?
    – asthasr
    Sep 6, 2011 at 1:14
  • 1
    I'm confused; first you say the app was developed in Visual Basic, then you say the server is running PHP. huh?
    – jhocking
    Sep 6, 2011 at 1:57
  • @jhocking: seems like he's saying the old system was a desktop app written in VB, and the new one (the one he's writing) is written with a LAMP stack.
    – Jordan
    Sep 6, 2011 at 4:10
  • Sounds like their previous app was written in vb, he's currently making a web front end for it. Sep 6, 2011 at 4:12

4 Answers 4


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.

The screenshot shows an alert box with a checkbox "Prevent this page from creating additional dialogs"

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.

  • 1
    The question didn't have anything to do with infinite or spam popups, so why are you mentioning it here? And I don't think its necessarily a bad thing that JS pop ups are unstylable. When used properly (for alerting the user to something MAJOR) they force the user to address them before doing anything else, which is sometimes what you want.
    – GHP
    Sep 6, 2011 at 13:39
  • This doesn't answer the question.
    – CaffGeek
    Sep 6, 2011 at 16:14
  • 1
    "When displaying an alert box, JavaScript stops executing until the user clicks" - this is true for a confirm() and prompt(); with alert(), the behavior is browser-dependent (execution may continue even when alert() is displayed - the rationale is "there's only one way out anyway"). Sep 6, 2011 at 16:21
  • 1
    @ Graham: You're right for infinite popups; I was off-topic on this point. I tried to reformulate this better. As for alerting for something major, see the fourth point of my answer: yes, you may want to have stop everything before the user confirms an action, but it does not permit you to block every tab of the browser, because other tabs do not belong to your web application. Sep 6, 2011 at 16:56
  • 1
    @BornToCode: there is no alternative. As soon as you show photos on user's screen, there is no way to protect them from being copied. As for your second question, you have to be more specific. Try ux.se. Nov 1, 2017 at 10:06

Bottom line: The default prompt, confirm and alert dialog boxes match the style of your browser, not the style of your site. Most UI people want all dialog boxes to flow with the UI of their site. They use modal windows to present messages and collect data using the same fonts and colors as the site's UI, not the default grey and blue of MSIE or FF.


You are only adding overhead if you don't need the fancy dialogs elsewhere, which you probably do. At that point it doesn't make much difference whether the functionality is included as part of the browser or as part of the framework you are using, and you may as well keep all your popups looking consistent.

While you can do a lot with javascript and no frameworks, I remember what it was like developing in javascript before the frameworks were available, and I wouldn't want to go back to it.


Because browsers don't handle them very well. As you may have noticed they are usually modal dialogs and not only prevent users from moving and resizing their browsers they also prevent other tabs from being accessed, which is very annoying.

For dialogs like confirm and alter I still think the browser should be enforcing the behaviour, and for the latest Firefox browser you can see they've fixed the problem I mentioned above. They use in page alerts that are scoped to the current page.

Therefore I suggest that you override the alert behaviour so that all browsers can handle (at least alerts) more elegantly.

A few summarised reasons:

  • This is the standard API and developers can figure out what you’re trying to do.
  • It’s more user friendly, and looks better.
  • Platform support, mobile sites might need the native API.

Not the answer you're looking for? Browse other questions tagged or ask your own question.