behind
the  
codes{

If you’re asking me what’s the most useful thing I ever come across when developing websites, my answer will be jQuery. In fact, that’s one of the top entries in my to-do list when doing website projects. So important and so useful to me, that it has saved my life!!! Well, actually it’s not THAT dramatic really… but with jQuery, it makes implementation faster, easier, and fun-er, thus giving me back those precious long-lost portion of time to get more family time, more game time, and–of course–more sleep.

How so? Quoted from their website:

……say what???

Allow me to break it down so it’s easier for you to understand.

jQuery is a JavaScript library, which is fast and concise

I hope you know what is a library (and while we’re at it, I also hope you know what is Javascript). A lot of programmers have their own collections of codes that they can reuse on all their projects. If you’re a web programmer, then most likely you have (if not, you should have) some kind of Javascript library as well. The codes in this library–functions, classes, etc–might come from lots of different sources, and might provide lots of different Javascript-related functionalities. Over the time, some things get added, while some other things become obsolete. Some areas got improved, while perhaps some others got broken in the process. And at the end, you might end up with lots of unused, not-so-useful, outdated, and buggy glob of messy codes in your beloved library.

Now there… pardon me of being prejudicely hyperbolic, but this is the tendency of having a one-person team of developing a library, applicable only to that one-person developer. But what if there are several dozens of developers? And they all share the same passion and goal? And all of them are experts (at least in their specific fields, in the big Javascript world)? Well, they will surely produce a very good code library, won’t they? At least the library will be well maintained and contantly being enhanced, of course!

And what if this library is used by lots of projects? And its user/programmer community are actively giving feedbacks to the library developers? And the developers are actually listening–where bugs are squashed, speedups are introduced, and feature requests are implemented? Certainly all these condition will lead to an uberlibrary, don’t you agree?

And jQuery is just like that: A Javascript library that is powerful enough to empower some of the biggest websites (Google, anybody?). Its operations are fast, and its features are concisely to-the-point on… continue to the next point, please.

Simplifies HTML document traversing, even handling, animating, and Ajax interactions

These four areas are the foundation of jQuery. You want a UI (User Interface) library? Sorry, it’s not in jQuery core–but you can use jQuery UI library instead. You want picture slideshows? Again sorry, it’s not in jQuery core–but you can use other libraries (or jQuery plugins) to achieve that.

Stopping here, some might have the impression that jQuery sucks, because it doesn’t provide all that we need. But actually that’s the point! jQuery is very powerful because it does not provide all that you need. Philosophically, who is “we”? You might need a library to do fancy client-side graph library, but do “we”?

So per their concensus, they (jQuery team) chose to focus on these four aspecs–concise! And by focusing on these only, they can make their codes run blazingly fast! See the point now?

…all these are for rapid web development

Given an HTML element, and considering that element might contain subelement(s), how do you get only the textual data of that element? Easy peasy… use innerText of course. WRONG! In case you don’t know, innerText only works on IE!!!.

That’s one example of how cross-browser incompatibility destroy our coding happiness, and sometimes take our sense of pride and accomplishment with it. We need to spend more time researching how this works on other browsers, as well as more time implementing the solution that will work on all browsers we support. Well sure some of you might know how to do innerText on FF and Chrome, but wouldn’t it be nice if all browsers work the same way?

jQuery to the rescue! To get the text, just use text property. That’s it, and it will run on all IE, FF, Chrome, etc. Don’t believe me? Try this code (or run it here):

<html>
<head>
	<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js"></script>
	<script type="text/javascript">
		window.onload = function() {
			document.getElementById("dst_no_jquery").innerText = document.getElementById("source").innerText;
		}
		$(document).ready(function() {
			$("#dst_with_jquery").text($("#source").text());
		});
	</script>
</head>
<body>
	<div id="source">This is <b>the <i>content</i></b> of a div.</div>
	<p>The content of the div above will be copied down here...
		<div>...without using jquery: <u id="dst_no_jquery">???</u></div>
		<div>...using jquery: <u id="dst_with_jquery">???</u></div>
	</p>
</body>
</html>

Not only that this code rules on all browsers, notice that it is also shorter to write, which leads to–you’ve guessed it right–rapid development! Ta daaaa!

There are other reasons why jQuery leads to faster development, for example:

• ability to chain operations, which leads to a leaner code,
• availability of numerous plugins you can use that suits your need,
• ease of DOM manipulation (including element selection and traversing them) makes the development more intuitive,
• straightforward event handling and trigger,
• simpler implementaton of animation and/or effects,
• and so on.

For all these things, you can check jQuery site’s tutorials (you can find other tutorials too on Google). I will list out my use cases on where jQuery helps my development, but meanwhile, you can go ahead and familiarize yourself with the power of jQuery!

Why not the other Javascript libraries/frameworks?

When I started using jQuery, what I needed was something easy to use, fast to learn, and–of course–fast. Based on my research, I set my eyes to four candidates: MooTools, Dojo, Prototype, and jQuery. Below were my findings:

• I used slickspeed to test the candidates’ speed, and found that Prototype is the slowest; I crossed that out.
• Also from slickspeed, I noticed that in some test cases Dojo produced errors/exceptions. Not wanting any side effects affecting my developments, I decided to rule it out as well.
• MooTools were slightly slower than jQuery, so I decided to learn both. However, in my subjective opinion, I felt jQuery was easier to learn, thus I was able to deploy my sites quicker.
• WINNER: jQuery

I understand that some of you might disagree, and I believe my conclusion here doesn’t really provide a thorough, scientific, and object evaluations. But I suggest you to try it, and I’m sure you’ll like it!

Questions? Problems? Leave a comment and I’ll try my best to help.