5 Reasons Why I Love (and Am Sticking With) jQuery

In the same way that I think that it’s safe to say that WordPress has become the defacto blogging engine on the web today (and possibly the most popular content management package, period), it seems to me that jQuery has probably also become the nearly equally dominant JavaScript framework. At the very least, it seems to be the one we’re talking about the most.

I think that there are a number of different reasons as to why this would be. Altogether, it’s just a really awesome framework that readily and easily extends what we can do with client-side coding routines. In this article, I would like to look at the five key reasons why I have personally and enthusiastically adopted jQuery.


jQuery’s ability to use CSS-like selectors in order to target certain elements or groups of elements within a document is, hands down, my absolute favourite feature. It’s just so incredibly useful. For instance, if I wanted to use CSS to style all the list elements in a list with the id of “mylist” I could do it like this:

#mylist li{ color : blue }

But let’s say I subsequently wanted to use jQuery to change the color of all these elements to red (likely based on some condition). Well, I could use the exact same selector syntax to accomplish this:

jQuery(“#mylist li”).css(“color”,“red”);

There are a couple of things that I really love about this. First, the familiarity makes the syntax very accessible and easy to learn for people who are familiar with CSS. This was the case with me when I first came to jQuery. I was already quite proficient with creating styles and had a solid understanding of how to target elements with selectors. Ultimately, this meant that I was able to pick up on jQuery’s selector syntax almost immediately, cutting down on the overall learning curve.

The other thing that this use of selectors does is to really simplify accessing different elements from the DOM. In plain JavaScript, we can access elements via their id, through the getElementById() method of the document object. To access a collection of elements, we would have to manually work through child arrays and, if you only wanted certain elements, you would have to do a bunch of cross checking.

With jQuery, the framework does all the heavy lifting for us, making it super easy to create rich, document-changing functionality!


Traditionally, if I wanted to attach a function to a particular event on an HTML element, such as a click, focus or hover, I would have to use tag attributes such as onclick, onmouseover or onfocus. These worked well enough and still server their purposes.

However, using jQuery, we can actually use the built in listeners to attach our functions to a wide variety of different events. All we need to do is use the following basic syntax.

jQuery(“#mylist li”).click( function(){ ... });

Now every time someone clicks a list item within the object with id of “mylist”, the defined function will execute. If we’re only working with one or two items, there are probably not are all that many benefits over using the HTML attribute method (other than cleaning up our HTML code). However, if we needed to apply listeners to more than just a few elements, the jQuery technique can be a far more efficient way of doing things.

Even better (from my perspective) is the ability to change event behaviours. Sometimes, there are circumstances where you may want to change the functionality that is executed on a particular event. As far as I can tell, there is no easy way of doing this when using the HTML attributes. Theoretically, we could clone a particular element, remove it and then replace the original with the clone, just changing the required attribute. It’s not a very elegant solution though.

Using jQuery, however, we can simply use the unbind() method.

jQuery(“#mylist li”).unbind(“click”);

jQuery(“#mylist li”).click( function(){ ... });

This is a super useful technique, allowing us to flip and switch functionality on the fly. It has probably saved me hours and hours of writing ugly, clumsy code to do this exact same thing.


One of the other things that jQuery is probably best known for is its ability to control on-screen animations, some of which can actually become quite complex. This is definitely a huge benefit of using the framework.

I remember creating my own custom animations with plain-Jane JavaScript, and while it really wasn’t all that difficult (just a bunch of math and changing CSS properties), it was a time consuming process that involved a lot of coding, testing, calculating and re-coding. Using the animate() method, or a number of others such as fadeIn() or slideDown(), in can take just a matter of minutes to achive effects that would have taken hours to code if we were doing it by hand.

For example, suppose we have a message box that appears on screen, perhaps reporting on errors or confirming that an action had been completed. As developers and designers with good usability habits, we need to provide the user with a way of closing the warning message, so we create a close (x) button. When the button is clicked, we could easily make it vanish by changing the CSS display property with something like this:

document.getElementById(“msg”).style.display = “none”;

The warning message would instantly vanish, and our goal would be accomplished. With jQuery, however, we can be a little more slick:


Simply put, this will cause the element to slowly fade out and vanish from the DOM. Ultimately, it achieves the same general purpose as the straight JavaScript technique, but the user experience is just a little bit slicker and more enjoyable. Though this example doesn’t use it, methods like fadeOut() also allow us to set options to control the speed of the animation, and even provide an additional function to execute once the animation is complete.

This extra animation functionality makes creating slick, animated UI relatively simple, even for beginners who have only limited coding experience.


One of the concepts that we hear associated with jQuery all the time is the plugin. There are all kinds of different plugins out there, with each building upon the existing core of the framework. I believe that, over time, some of the most popular have even been integrated into the core.

Basically, all a jQuery plugin really constitutes is an extra block of code that adds an additional method (or methods) to the core jQuery object. Thus, whenever a new jQuery object is initiated, the plugin method will also be included, allowing it to be executed just like any other method.

The simple beauty of this is that it makes the framework hugely adaptable. If we were to include all of the plugins that exist out there in the core, jQuery would become a huge, bloated monster, both in terms of its overall size in bytes, and in terms of the amount of memory that would need to be allocated with every initialization of the object.

By focusing on a basic plugin architecture, though, jQuery itself can remain smaller and leaner, and developers can choose to include the functionality that they need while excluding the functionality that they don’t – sometimes even within the same site or application.

For instance, in one project that I have been working on recently, there was a section that needed to be able to generated data tables. I used jQuery AJAX to fetch the data, and then a fully featured jQuery plugin to transform the simple, static HTML table into a fully sortable, searchable and paginated table that made for a far better user experience. However, I only needed that plugin to be visible to a certain section of the overall project, so I used some basic conditional logic to only supply the plugin when it was needed, thereby preventing jQuery itself from becoming bloated with unnecessary methods.

Regardless, there are hundreds and hundreds of different plugins out there (many of which are variations on solving the same basic problem), and when you include those within the overall jQuery family, the possibilities suggested by its functionality are, theoretically, endless.


Like any open source project, jQuery has also developed its own, dedicated community of users and developers. In many ways, it reminds me of the WordPress community. Thousands and thousands of people are using and contributing to jQuery every single day, generally by means of the plugins that we were just discussing. Sometimes, as is the case with my own simple Contained Sticky Scroll plugin, they are authored by a single developer. Other times, a plugin may be created by a team, or perhaps originally created by one person, but expanded upon and supported by several others.

So what’s the advantage of this?

Well I’m sure you’ve heard the saying that two heads are better than one, meaning that having two people thinking cooperatively about the same problem is likely to result in a better solution that if just one individual was working on it. If that’s true of just two minds, how much more would it be true of thousands and thousands of minds? Granted, not everyone in the jQuery community is working on the same problems at the same time, and we frequently see multiple solutions to the same problem (think of how many tooltip plugins there are out there), but the continued, innovative problem solving moves us ever forward.

Ultimately, the existence of the community that has sprung up around jQuery also provides a great deal of support for beginners, or even intermediate users (which I consider myself). I still frequent forums from time to time, in an effort to find a solution to a particularly vexing problem, and with the vast number of jQuery experts out there, I am usually able to track down an answer to help me do what I need to get done.

This kind of vast and accessible support network is just one more reason why I love working with jQuery and find it to be one of the single most valuable tools in my development toolbox.

But What About the Others?

Yes I realize that there are some other JavaScript frameworks out there. MooTools seems to have a pretty loyal following. Have I tried them? Not at all. There has really been no need. jQuery has been able to do pretty much everything I’ve ever needed of it (and a whole lot more). Given the benefits that I can derive from its selectors, events, animation, extensibility and community, why would I use anything else?

Until I’m presented with a framework that can do something that jQuery can’t, or which can do it in a clearly superior way, I’ll be sticking with my current choice. If it’s not broken, as they say, don’t fix it.

Moreover, given the rampant popularity of jQuery, I cannot help wondering if the future holds the possibility of it becoming more than just a framework. Could it be possible that eventually browsers will start supporting jQuery natively? It certainly doesn’t seem beyond the realm of possibility, especially as we move towards richer and richer web apps that ultimately require the broad range of functionality that jQuery has to offer.

It may not happen at all, but I think that if any framework has the potential to become a natively supported extension of JavaScript, it would almost certainly be jQuery. Call me a romantic, but and I guess that’s just one more reason to love it and stick with it.

Chris Stark