Prototype

Prototype is comfortably installed in a lot of developers mind because of two reasons : it was the first widely used and script.aculo.us. Being the first accepted library is a hard thing to do and it will always help them. Scriptaculous (I hate to write it with the dots) had an incredible effect on the popularity of prototype. For the first time, we could do “flash animation” without using flash. This was instant popularity.

jQuery

jQuery is one of the bastard child of prototype. It reuses the $() function but brings it to a level you never could have hope for. In fact, jQuery is almost completly based on the $ sign. Why? Maybe because it’s fast, maybe because it’s trendy. I don’t know. Example, you want to download a JSON from a server, $.getJSON(“http://www.thesite.com/thejson”).

Reason #1 : The selectors

jQuery supports a lot of selectors. And when I say a lot, I really mean a lot. First, there’s CSS selectors. You just have to apply what you know about CSS and you can write many complex selectors.

Second, there’s XPath selectors. When I was young (sic!), I wrote a lot of XSL. And when I say a lot, I really mean a lot. XSL makes an intensive use of that XPath thingy. Because XHTML is basically XML, we could use XPath to easily navigate throught the DOM. The problem was that before jQuery, nothing could do that. Now, we can!

In comparison, prototype just has the $(‘theId’) to select a element. Ouch!

Reason #2 : The Attributes

It’s easy to add/remove attributes to any HTML element. I use it when I create new elements or when I need to add/remove a css class on an element. The interesting thing is that you can chain them and it will work. Example, I want

You can add as many as you want…

Reason #3 : Ajax and JSON

Once again, ajax is now easy as 1,2,3. I wrote an article on JSON and in my mind, there’s no real alternative to JSON. jQuery helps you with it.

It’s a little more complex with prototype.

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.

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

Ajax forces javascript

Most people hate javascript but they want to do ajax, this is a duality. How do they overcome that problem? By using tons of javascript library and copying javascript snippets from tons of different sites. You know what? That won’t be any help for having well structured javascript. You just have to take javascript as seriously as your server-side language.

The structure

I saw a lot of web applications that were (almost) well documented. The developers spent hours thinking about doing a framework (argh!) that would help him handle all the code he will one day try to write. They didn’t have any thought about how they would write the javascript that will handle all that shit. “It will just flow” they say. No. I won’t “just flow”. It will be a mess.

Think about the javascript you’ll have to write and treat it with respect.

DHtml???

Once again, people do not make any difference between ajax and DHtml. When something in a page moves, it’s ajax. No, it’s DHtml. Ajax is just the response from the server that triggered the moving request. With DHtml, you can dynamically change the Html of your page using Javascript/DHtml (hey, I’m not talking about the innerHTML property). That’s where the javascript librairies (like jquery, script.aculo.us or mochikit) will help because the basic DHtml offered by javascript (with the DOM) is a real pain in the ass.

And CSS???

I also wrote Do not use the style property on HTML objects. That’s where CSS enters the battle.

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.