Do You Really Need jQuery?

Apologies for the link-baiting title because this isn’t an anti-jQuery article. The same points can be made for any JavaScript library — including your own. However, jQuery is the favorite choice for many developers and some will add it before commencing any JavaScript work.

jQuery is an Abstraction

If you think web development is tough now, try developing JavaScript code in a browser from five or ten years ago. The typical problems:

1. DOM navigation and manipulation differ. For example, Firefox (correctly) included whitespace in the DOM, IE6 didn’t. Therefore, you couldn’t depend on node.firstChild returning the same thing.
2. Ajax was natively supported in most browsers, but an ActiveX control in IE (even though Microsoft invented XMLHttpRequest).
3. IE had a different event model but even the other browsers had their share of inconsistencies.
4. CSS2.1 support varied immensely.
5. Animation could be difficult especially when coping with box model differences, form controls and iframes (IE6 placed select boxes and iframes above everything else on the page).
6. Developer tools were rudimentary. Prior to Firebug, Firefox’s error console and IE’s clunky modal error box were the only built-in browser tools.

Developers had to write abstraction functions to get around these issues. jQuery, Prototype and MooTools evolved from the primordial chaos; the libraries smoothed over the cracks and provided useful missing features such as DOM selection from CSS selectors.

It’s important to remember that jQuery and the alternatives are written in JavaScript to make writing JavaScript easier. They’re not languages in their own right.

Going Naked

In 2013, the top five browsers are closer than they’ve ever been. The vendors have adopted standards and while some browsers may be missing certain HTML5 APIs, the core JavaScript tenets of DOM traversal, manipulation, event handling, server communication and CSS effects are well implemented and documented. If something works in IE10 or Firefox 23, you can (almost) guarantee it’ll be fine in Chrome 27 and Opera 12.

So why use a library when the problems it solves no longer exist? Naked JavaScript will always be faster than calling a library which abstracts the native call. In some cases, naked alternatives are also more useful. For example:

var i = $(".myclass");

uses jQuery to find all elements on the page assigned the class “myclass” at the point it’s run. However:

var i = document.querySelectorAll(".myclass");

will always be faster. In addition, if you used getElementsByClassname, the returned value is a live collection. In other words, the collection of DOM nodes represented in i will magically change when elements with the class “myclass” are added or removed from the page. The jQuery version must be run repeatedly to achieve the same result.

The primary benefit of the jQuery version is that it’ll work in IE6 and 7 (assuming you’re using jQuery 1.x). If you’re not developing for those browsers or have moved to jQuery 2.x, the main advantage is a simpler syntax — but remember you’re loading and parsing 30Kb of compressed script to provide that service.

Break the Dependency Chain

I’ve been using jQuery and my own smaller libraries for many years. Why? Mostly habit.

As a proof of concept, I decided to re-write the JavaScript code on a simple site which had some basic DOM manipulation, form validation and effects implemented using a small library. IE6 and 7 support wasn’t important, but IE8 had to work which meant I couldn’t rely on HTML5 form checking such as the required attribute. I still abstracted a few browser features but mainly for brevity, e.g.

function $I(id) {
	return document.getElementById(id);
}

The result: a 15Kb (combined and minified) JavaScript file was reduced to 3Kb using raw JavaScript code. An 80% saving.

Admittedly, it’s not proof you would achieve that outcome on other projects and a 12Kb saving would barely be noticeable. However, it did illustrate that I didn’t need all the functionality offered by the minimal library I was using. You certainly won’t be using all the functionality offered by jQuery even after removing unnecessary modules. Worse still, developers often use multiple libraries because they want specific features and/or plug-ins.

Never Say Never

I’m not saying you should never use jQuery. Nor should you underestimate the enormous development effort and assistance the library provides. Some level of native browser abstraction is always required no matter how you approach the code. Consider Ajax — you wouldn’t want to re-write XMLHttpRequest API calls for every server communication. A large client-side application will need a set of common components and jQuery or another library may be a good fit.

However, if you’re not supporting old IEs and want to provide the fastest, slickest, most compatible experience then take a hard look at the problem you’re trying to solve. For example, if you’re writing a cookie-handling utility, there’s no point in making that a jQuery plug-in or tying it to another library. Yet you’ll find cookie handlers throughout plug-in repositories even though it’s simpler and more effective to create a standalone module which works anywhere regardless of other code.

jQuery is a comforting blanket but, sometimes, it’s good to venture out naked into the JavaScript world. You’ll enjoy the freedom and learn far more about how browsers really work.

Coming soon: Naked Equivalents for jQuery Methods…