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.

Javascript is not secure

I repeat : javascript is not secure. Your code is readable and it can be modified by anyone. It is great when you want to do a bookmarklet. It is not so great when you want to have a hard as a rock web application.

Example, you want to validate that a manually entered date is less than today. The javascript code for it is not complex.

[source:javascript]
function validateDate(theDate) {
var now = new Date();
return (theDate < now);
}
[/source]

But anyone could override the function to always return true and all the dates that he enters would be good. This is bad.

Always validate on the server-side

Whenever you have to validate something in your web application, use the server-side. I know, it is redundant and long to do but you must do it. Someone once said that you must consider every input from the user has evil.I prefer the word dirty. Users sometimes don’t want to be evil to a web application but they are. And sometimes, users want to be evil.

If you have little time to implement an application, just do the server-side validations.

You must consider javascript validations as “pretty” validations. It validates things but it just to make your application prettier. In facts, it helps you with usability and it simplifies the life of the users of your application.

The “cheap return” method

To avoid to write a lot of code on the server-side for validations, I would suggest you a simple method that will help you code faster. It is called the cheap return method.

1. You do all the validations on the client-side in javascript.
2. You do all the validations on the server-side but if it fails, you display a generic page to the users that says that it has failed.
3. You pretend to have done it completly on the client-side and server-side.
4. You spend the rest of your time watching the ceiling.

The idea behind that is that if all javascript validations have passed, the users must have done something between the client-side and server-side. So, he is responsible of that error.

I don’t really like it either…

innerHTML seems easy

I like easy things : Diner Kraft and automatic cars. It’s so easy to write HTML, why should I spend time with the DOM when I can easily do it with innerHTML?

With the Dom
[source:javascript]
var aLink = document.createElement(“a”);
aLink.href=”http://www.javascriptkata.com”;
aLink.appendChild(document.createTextNode(“Javascript Kata”);
document.body.appendChild(aLink);
[/source]

VS with innerHTML

document.body.innerHTML += "<a href=\"http://www.javascriptkata.com\">Javascript Kata</a>";

Why???

innerHTML is dirty

It may look good at first sight but it’ll look real bad the next morning without make-up. Did you noticed the \”? Prepare yourself because with innerHTML you will have a truck load of these. Take a look at this.

document.body.innerHTML += "<a href=\"http://www.javascriptkata.com\" id=\"theLink\" class=\"aLink\" title=\"Javascript\">Javascript Kata</a>";

Ouch! My eyes burn.

A lot of HTML

iInnerHTML looks worst if you have a lot of And now, what if you have a lot of HTML code embedded in your javascript, it will win the war over you. I tell you.

innerHTML and ajax

I have an idea, if my ajax request returns some HTML, I could use the innerHTML property on an HTML object and assign the ajax response to it and it would be magic!

NO! In fact, you can do it but for every reasons in the world, don’t ever do that. Yeah, I know, Yahoo!TV is doing it but don’t fall in that trap.

Ajax should return data to your application. Why? Because you’ll never know what you’ll have to do with that information. For the moment, maybe you just do a simple display of the data but sooner or later, you’ll have to re-use for another section of the page. If you return HTML, you will end up parsing it to extract the data contained in it. I tell you.

By the way, forget about that old XML thingy, try JSON…

It is not standard

It doesn’t really matter to me but if you’re a W3C-compliant kind of guy, that may be a good point.

Your friend is a library

You have a lot a HTML code to produce through you javascript, go and get a good library. I can’t tell you which one to use because they all have the ups and downs. Choose one and stick to it.

• jquery
• mochikit
• prototype
• another javascript library

The style property has a precedence on every style

Because the style property is so “close” to the HTML object, it will override every other style from a CSS file. So if you begin to write styles in your javascript code, you’ll have to do it all the time. It might be easy and clean for a basic project but it will become a mess in the future. You should centralize every style in your CSS files so you won’t have to search where you assigned a style.

Example

I have this CSS

[source:css]
div.theCssClass {
background-color:blue;
}
[/source]

and I create a new HTML object of this class

[source:javascript]
// I create the DIV
var div = document.createElement(“div”);
div.appendChild(document.createTextNode(“This div is a test”));

div.className = “theCssClass”; // I assign theCssClass
div.style.backgroundColor = “red”; // The background is red

document.body.appendChild(div);
[/source]

You’ll see that the even if I set the background color to blue in the CSS file, the background will be red because I used the style property.

The !important in CSS

If you want to override a style assigned in javascript, you could always use the !important statement in your CSS file.

[source:css]
div.useThisOne {
background-color:blue !important;
}
[/source]

Use it only if you really have to. I wouldn’t recommend !important because it breaks the default behavior of styles and can become very messy. When all is important, nothing is important.