Chris Love's Official ASP.NET Blog : Why Its Time to Sunset jQuery

I owe so much to John Resig and the jQuery team for creating such a wonderful framework. I have staked most of my recent career on jQuery the way I staked my career on ASP.NET back in 2001. I have built many applications using jQuery over the past five or so years. Thanks to jQuery I now know how to build rich, fast, scalable client heavy single page web applications. Without jQuery I am not sure I, nor thousands of other developers would really want to develop AJAX applications. The web has pushed its limit largely due to the power and ease jQuery made building modern web applications.

The way browsers work today has changed in many ways thanks to jQuery. Just a few years ago DOM parsing was rather complicated, jQuery made that easy. DOM manipulation was not straight forward, thanks to jQuery developers can manipulate with little effort. Today 96%+ browsers in use today support document.querySelectorAll, which accepts a CSS selector and returns a list of matching nodes.

In many ways thanks to jQuery, jQuery itself is no longer needed. There I said it.

The ubiquitous adoption of mobile platforms is another major factor leading me to the point where I feel comfortable saying jQuery is no longer needed. I am on a mission to purge jQuery out of my primary web architecture. Instead I have spent some time, and not that much to be honest, learning how to build rich HTMl5/AJAX applications directly against the native browser API.

As the jQuery team marches toward a 2.0 release it intends on purging the many hacks jQuery uses to provide obsolete browser support. Basically they will no longer support IE 8- and many old versions of FireFox, Chrome and Safari. My guess is they will still have a lot of scars in place to support the many WebKit instances proliferated and never updated by the Android ecosystem. While the 2.0 release promises to be smaller and faster its really not something I feel I can wait on any longer. To be honest when I first heard about jQuery Mobile I anticipated a mobile optimized version of jQuery, not another heavy UI framework, that was over two years ago.

You can call it Vanillajs or maybe going native, but it is rather simple to do. first you need to make the assumption of a browser baseline. For me it is at least IE8, however that is quickly moving to IE 9 as most should upgrade to at least IE9, even stodgy old enterprises. I will write about them in another post. The mass adoption of mobile means we have a broad set of new devices that have replaced old devices running old, outdated browsers. This means a quorum of a potential audience is running a browser capable of supporting a Vanillajs web application.

If nothing else you will experience a must faster web applications. Back in November I showed how using the browser's native DOM selectors was orders of magnitude faster than using jQuery's Sizzle engine. This is just the first and easiest step a developer can take. Once you start down this path you will quickly realize how simple it is to replicate many of the functions and utilities included in jQuery using the native JavaScript APIs.

So lets look at some quick examples of how to migrate from a jQuery based application to a native AJAX application.

DOM Selection

The simplest 'catch all' native selector methods are document.querySelector and document.querySelectorAll. The different between the two is the first one returns a single node, the second a nodeList or array of nodes. For the record a node is a JavaScript object representing a DOM element. The querySelector methods are simple because they accept a CSS selector, just like jQuery does, and returns any target element(s) matching the selector. These methods are all a part of the Selectors API, http://www.w3.org/TR/selectors-api/.

The following example would return the first H1 enclosed in a header element.

var mainTitle = document.querySelector("header > h1");

The next example selects any IMG tags within a paragraph with the CSS 'emphasis' class applied:

var emphasisImgs = document.querySelectorAll("p.emphasis img");

The original native element selector method is document.getElementById. This method will return the node object for the element with a specified id. If not element exist it returns null. This is by far the fastest selector, but it is also limited because there must be an element with the id of course.

var mainView = document.getElementById("mainView");

Other element selector methods include document.getElementsByName  and document.getElementsByTagName. Support for these methods is limited to the newest browsers, so be careful when trying to use them for a little while longer. Both return a nodeList of elements matching either by the name attribute or element type.

A nice thing about these selection methods is they are all supported by the element or node object as well. This means you could select a parent element containing a series of child elements and select matching elements within the main parent. This would be similar to the jQuery constructor using the parent selector, $(".childElements", "#parentId").

Changing An Elements Style

In jQuery you can change any style property by calling the $.css method, passing the property name and a value. It does a lot of cleanup for you, etc. Its actually where the beauty of jQuery shines through. But if you really think about it, directly setting a style property is not that hard. The following example shows how to set the marginRight property:

mainView.style.marginRight = mWidth + "%";

So where is the benefit? I mean the $.css method wraps things up nicely for developers. If you look at the actual jQuery source for the $.css method it is over 500 lines of code. That means it does a lot of things and takes time. Setting the properties directly is much faster.

You can read more about the DOM style object's properties, http://www.w3schools.com/jsref/dom_obj_style.asp. If you want to get an object containing an element's used style values you can call the getComputedStyles method, https://developer.mozilla.org/en-US/docs/DOM/window.getComputedStyle.

DOM Manipulation

After DOM selection, manipulation is probably the next more important feature jQuery offers. But that too can easily be done without jQuery. Like the jQuery css method, the manipulation module us over 600 lines of JavaScript. There are actually a whole range of DOM manipulation methods built natively in the document and node objects, https://developer.mozilla.org/en-US/docs/DOM/element#Methods. You can insert elements before and after target elements, select child nodes, etc.

https://developer.mozilla.org/en-US/docs/DOM/Node.firstChild

Here is an example method from my panoramaJS library. It ultimately gets the first panel and moved it to the last position in the list. Ultimately this how the carousel is continuous in either direction. I chose this method as an example because it show how you can manipulate a node's style and move elements around all in one quick coding motion. The getFirstPanel method actually loops through the childNodes to get the first panel at this time. I am working on a cleaner solution. The reason I did that at the time is the firstChild will return a #text node if there are characters before the actual first child element, admittedly one of the quirks of the native API.

moveLeftCallback: function (parentNode) {
 parentNode = parentNode || this.panelbody;
var childNodes = parentNode.childNodes;
 parentNode.style[this.support.transition] = this.fastTransition;
 parentNode.appendChild(this.getFirstPanel(childNodes));
 parentNode.style[this.support.transform] = "";
this.moving = false;
this.executeMove();
}

I realize riding without the jQuery training wheels is not for everyone, yet. But jQuery is something every web developer should start trying to live without. Start with using the native DOM selectors and go from there. Going 100% VanillaJS is not something even the best developers will do efficiently right out of the gate, I personally have a long way to go. jQuery does a lot to mask some of the nuances and bug artifacts from old browser versions, especially WebKit and obsoleted Internet Explorer. But the beauty of jQuery is how it helped force and even provide some awesome guidance for browser manufacturers add native functionality that we as developers need to make modern web applications.

But sadly as features and functionality have been added to jQuery so has the weight. Despite the news about gigabit Ethernet and powerful CPUs, the market has gone mobile. This means a proliferation of AMD and lower powered Intel CPUs connected using expensive 3/4G connections. Bandwidth and performance matter. With the average web site size reaching sizes that would not fit on a 3.5 inch floppy, http://httparchive.org/trends.php, an effort must be made by developers to remove things that just are not needed.

According to HTTP Archive the average site contains over 220kb and 20 files of JavaScript. My personal research routinely reveals sites using in excess of 500kb to perform minimal activities. Even the minimized jQuery is 91kb today. I admit there are many places where jQuery still fills a need to either make things a little easier or provide functionality that is just not available natively, that will always be the case. But over the past few months I have found these scenarios to be less and less. Instead I can find the native functionality and if needed I see how jQuery, https://github.com/jquery/jquery, or someone on Stackoverflow solved the problem. Ultimately I gain two things, a richer understanding of the browser platform and much leaner and faster code.

I encourage you to give it a shot. Write your next application, library or just code for fun without jQuery. See what you can do. When you get done write the code using jQuery then compare the results. Look for file sizes and performance. You can check the performance on a site like http://jsPerf.com. When I have time I like to review popular tests myself to see what others have found, http://jsperf.com/popular.

Still think you need a one library serves all JavaScript framework? Think again there are hundreds of great micro framework available that provide a particular need. Often these libraries can serve an application better because they provide only the functionality the application needs, not thousands of lines of unused JavaScript and unnecessary hacks. Visit http://microjs.com/ and search for the functionality you need.

I don't hate jQuery, I love it. But sometimes there just comes a time to do things yourself and leave the comfort of your home. Try it I think you will be glad you did.