Do not use the alert function in javascript
Picture yourself on a beautiful beach on a warm day. The sounds of the waves is music to your hears. You’re on a comfortable chair with a laptop on your knees connected via an incredible WiFi. You’re using a brand new web2.0 application that must be the gratest web site on the web. Then, you see an infamous alert from javascript…
Back to reality
This alert box from javascript brought you back to reality. You’re in your shitty room, alone. The smell is disgusting. Everything is dirty. All because a developer has used the alert function to tell you something in an application. Don’t let this happen on your web application. Never, ever, ever use an alert box.
History of the alert
The alert was invented in the web1.0 era when it was the only way of showing a dynamic message to a user. That was the time when people loved win32 applications because they were so easy to use (compared to a web application). To have a little bit of win32 in their web world, they (some bad people) created a monster : the alert function that shows a win32 window.
It was it a big mistake because lazy developers still use it because it is so easy. Don’t fall in the trap. Do not use the alert function.
The problem with alert
The user have to click on the message before he can do anything else on the page. Users hate to click. Don’t make them click and show an unobtrusive message that the user doesn’t have to click to continue.
What should I use instead of alert?
Anything else. This includes (but is not limited to)
Light boxes
I personnally don’t like light boxes but they have the momentum at this moment. There are hundreds of library that can help you with them so don’t implement another one and re-use an existing one please…
Contextual messages
Why not show a message where it happened. A little knowledge of DHTML and you’re ready.
Example. On Ecstatik! (a project on which I worked), when there’s an error with the ajax vote, the label “I laughed!” is changed to “error!” written in red. Maybe it’s not the idea of the century but it works and it tells you where the error is.
Fading in/out messages
These ones are more difficult to do but Google and Wordpress do it elegantly. Use a library with a fading in/out function and show a message at the top of the page (or anywhere visible by the user). The user will get used to see messages at this place and will like the fact that they don’t have to click.
Note
I expect a lot of people to tell me that I use them in almost all my examples. These are examples and I don’t want to begin to write DHTML just to show the result of bunch of javascript lines.
RSS without the echo chamber
I’m one of those late to realize that “alert” isn’t a modern way of talking to your users. I saw those fading in/out messages a couple of times and I have to say that I really like them.
I don’t think the first one was a win32 window.
The alert function on the window object originated with Netscape 2, Microsoft added it to IE 3.
Back then (as now) Netscape was available on many platforms other than windows, so the win32 library wouldn’t have been practical.
Otherwise, nice post
@Paul, the story of the alert function might not be accurate. In fact, I invented it for fun (shame on me…) and to tell the people how outdated it is.
I promise that I won’t invent historical events anymore…
About the fade in/out message. What happens when a user clicks on something that will produce a message but does it and walks away to get some coffee or alt-tabs to another app. By the time they get back they may be lucky to see the error message disappearing before their very eyes without enough time to read it. Yes they look cool and all but be careful how you use them.
@Sam, there’s no magical solution to replace the alert box. You just have to take the time to think about it seriously before doing it. If the one and only solution you see is a alert, do it. But don’t consider it as the “default” way of doing it…
[…] Do not use the alert function in javascript A discussion of why the JavaScript ‘alert()’ function is evil. In my opinion you should only use it for debugging purposes, not as a way to communicate with users. (tags: programming javascript development) […]
Your alternatives to the alert box, while elegant for sighted users, may not work for vision-impaired folks who use screen readers. Screen readers only let a user “see” one word or element of the page at a time, and if the reader doesn’t register the fact that something has changed on the screen, it cannot go back to that part of the screen and read it off to the user.
Most screen readers, however, will recognize the Alert box and read it off to the user.
Hmmm, Brian brings up a really good point.
I’m always worried about how to get a lot of our web usability stuff to be somewhat 508 compliant.
In addition to the vision impaired, many so called drag-and-drop aren’t usable by those who can not use a mouse. When you see the news with soldiers coming back paralyzed and using a computer with a mouth piece, I can’t help but think that maybe a more simple interface might be better.
The truth is I don’t know the answer. I do think that these discussions will help lead to improvements all around (if anything, just by making people think about it a little more).
I think that the only way of being impaired-friendly is to have a complete different site. A “text version” site. It’s nearly impossible to easy to use to both worlds at the same time…
[…] Dan Simard has created JavaScript Kata as a place for us to get jiggy with JS. It isn’t in quite the same spirit as the Code Kata, as it contains items such as don’t use the alert() function. […]
I recently replaced all “alert”, “prompt”, and “confirm” from my project with Prototype Window
Probably most pathetic thing I have ever heard about alerts…
Its same as saying that do’nt use apples instead use bananas.
Dan, I came here to say the same thing as Brian, but I’m shocked to see the following comment: I think that the only way of being impaired-friendly is to have a complete different site. A “text version†site.
First of all, separate is not equal. Your argument isn’t much better than the same argument for racial segregation in schools. I’d hardly consider it “friendly” to shuffle someone off into a corner where they’ll be less of a nuisance to our pretty Ajax interfaces.
Where your argument leaks with blind users, it holds nothing for partially vision-impaired users. Better yet, dexterity-impaired users. Try this. Put down your mouse and try out ANY–I repeat, ANY–modern DHTML interface out there and post one that you consider to be usable. I bet you’ll be annoyed within two minutes. If for no other reason, no one gets focus() right on any of the libraries.
For example, the Prototype Window mentioned in the comments isn’t even dismissible without a mouse click. That’s hardly a replacement for alert.
I’m not saying I love alert. I think it’s as ugly as you do. I’m saying it’s not dead yet. It will never be until DOM-API and ARIA are standardized and well-supported.
@James
I’m not a pro of blind-user enhancement but I just think that to be nicer to them, we should just do another site. A site that their vocal-browser could read really fast instead of a site that’s “just good” to both world. They are just like you and me and they want to scan quicly a page. We are lucky and we can do it with our eyes. They have to do it with their ears… why shouldn’t we treat them with the respect they deserve?
@MAX
I was thinking about writing a article that was basically saying “Do not use apples, use bananas”. You have been quicker than me…
@Dan: Respect? Exactly, which is why we use headings (screen reader users can skip around) and link lists (announce number of links, skip full list) and style them with CSS now that it’s supported. The same type of enhancements can/will be made with updates coming in DOM-API and ARIA.
You missed my second point about dexterity impairments though. Accessibility is not just about blind people. Many people can see just fine but can’t use a mouse. Most DHTML interfaces ignore this group of users, too.
[…] Dan Simard has created JavaScript Kata as a place for us to get jiggy with JS. It isn’t in quite the same spirit as the Code Kata, as it contains items such as don’t use the alert() function. […]
I use alert() a lot for debugging. Recently though I’ve found myself to use less of it thanks to firebug and console.log(). It seems instead of putting an alert I can use console.log(myvar) to output the value of myvar in the firebug console. Neat !
This is something that has never crossed my mind, even though alert boxes annoy me when I get them. I’m gonna start changing all my form checker scripts with this kata.
The alert is also a blocking operation so your asynchronous calls will all have to wait until the alert is cleared.
Hi can we log alert text into a file
for eg,
I ‘ve gor alert(responseXML) where response
is too huge to read and debug
how can we log this into a file or some
place where it is readable?
@sree, you can’t create any file in javascript. It would be a big security problem.
Dan… you can use Javascript… with or without a library… to log alert-type info into a text-field or pseudo-window on the same page, and then once the event or process is complete, the user can manually copy the text in this field, and paste into a NotePad or WordPad file. I do this often when I am debugging a program.
You can set something up with Prototype or dojo or jsQuery..
BUT, I have found 2 tools that do just the debug-tracing activity quite easily.
jsTrace
http://www.easy-designs.net/code/jsTrace/
jsTracer
http://jstracer.sourceforge.net/
Interesting discussion.
But I have a question…
What if you want to stop execution/parsing of the current page by the browser until the user clicks “OK”? I wish there was another way but I can’t think of any way to do his except by using the alert function.
Is there any other way of doing this?
I always love the alert box cuz it snaps the reader’s attention.
Very useful and annoying if you was going to just make an surprise. ^^
Thanks for the light box code though!!!! It does work subtley…
You’re hard against the message boxes. They can be useful, in some cases. In a web application, it can be needed. But in web site, I agree that message boxes are as annoying as popups.
So, FYI, you can read and write through javascript embeded in a web browser. In Gecko, you have to ask user for that privilege, and in MSIE you just use the right ActiveX (so MSIE must ask the user for… at least).
(Sorry for my english, I’m french)