jQuery vs. JavaScript: Moving Away From jQuery

March 11 2014 Development

By Matt Mewton, Front-End Developer

Since its inception in 2006, jQuery has become one of the most popular JavaScript libraries around. In fact, it has become so popular that some developers are learning how to script in jQuery before they learn to write similar commands in JavaScript. One of the main reasons for this is the library’s simple syntax, making it relatively easy to pick up. In addition, the benefits of the jQuery plugin library can speed up development time by allowing developers to reuse existing ideas and write minimal custom code. However, I’ve been relying on jQuery less and less in our projects lately as a whole. Here are a few reasons why I think this is happening:

DOM Manipulation

I recently faced a conundrum while working on an RSR project. Do I use a jQuery element or a Document Object Model element? After much debate, I found that using the DOM was much simpler and more efficient. My problem was I needed a way to get all the elements of a class, find the ID of each of those elements and iterate through them accordingly to perform an action.

If I were using jQuery, I might try and do something like “$(‘body’).find(‘.foo’).” This line of code produces a jQuery element,  but that’s not really what I need. Once an element has been cast as a jQuery element, it loses access to some DOM properties and methods. That means I may need to write extra methods and functions, via jQuery, to get around the fact that we no longer have access to a basic DOM element. This has the potential to make our code more bloated and, in some cases, harder to read and maintain.

If we write “var element = document.getElementsByClassName(‘foo’)” and then call “element,” we get four DOM elements. We can then use the JavaScript “for” loop to iterate over each object and get the ID just like this: “element.id”. Simple, efficient and easy to gain control over the elements we want to manipulate.

Cross-Browser Benefits

Although one of jQuery’s benefits is cross-browser standardization, it doesn’t have an answer for everything. Suppose I want to disable a form button. “$(‘button’).attr(‘disabled, ‘disabled’)” doesn’t work in all browsers; but “document.getElementsByTagName.disabled = true” does. This can save many headaches, as debugging form-element styles in IE and Firefox is still a cumbersome process. Several other methods can also come in handy for adding and removing classes, or altering the HTML of certain elements, which are things we can do in jQuery but don’t take that much extra effort to write in plain JavaScript.

CSS3 Transitions

As recently as two or three years ago, a lot of interactive web animation was done through various jQuery commands. Methods such as “slideDown,” “animate,” and others became ubiquitous, and for a while this was one of the primary uses of the jQuery library. Now, the language of CSS has evolved to allow more flexibility when creating these types of animations, and most modern browsers have begun to incorporate these new CSS3 properties. There is now less of a reason to need to use jQuery to animate a menu up and down, for example, when the same can be accomplished in a CSS file. As CSS3 transitions are already extremely popular, I suspect it won’t be too long until the vast majority of front-end developers will rely exclusively on CSS3 instead of jQuery for simple animations and effects.

These are obviously small examples, and there are many concepts here that can be explored further. While I’ll keep jQuery around for now, I’m enjoying working with pure JavaScript. Not only is my code more efficient, I’m learning more about browsers and gaining a stronger understanding for the core of the language. I’ll take an educated guess and say that this is only going to help my development skills as I move forward. So the next time you find yourself using a jQuery selector, do a quick search for its JavaScript equivalent instead. You’ll probably be glad that you did.

View Archive