jQuery Obsolete?
jQuery Obsolete?

I owe so much to John Resig and the jQuery team for creating such a wonderful framework. I staked much of the middle years of my career on jQuery the way I staked my career on ASP.NET back in 2001.

But the web is in constant forward motion. Today I am largely serverless, leaning on nodejs Lamnda modules on the server, not ASP.NET and vanilla JavaScript instead of jQuery.

I built many applications using jQuery over the years. Thanks to jQuery I now know how to build rich, fast, scalable progressive web applications.

Without jQuery I am not sure I, nor thousands of other developers would really want to develop modern web applications.

The web pushed and continues to push its limits 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. For years 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 all 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.

Active jQuery Usage and Its Problem

According to BuiltWith jQuery is 'used' by over 80% of the top 1M websites. That is an impressive statistic. I will dive into reasons why it has maintained popularity a little later.

builtWith jQuery Version Usage Statistics
builtWith jQuery Version Usage Statistics

But first, lets dig a little deeper into the versions of jQuery. The library's usage has become very fragmented, with most sites not updating to the latest version.

The current jQuery version is 3.4.1 and it is the least used.

The original jQuery version, 1.0 was released on August 28, 2006. Over the next 10 years jQuery saw 12 'minor' version updates to the v1 branch.

On April 18, 2013 jQuery 2.0 was released. This branch had two minor updates released.

Version 3 was officially released on June 9m 2016 and has released 4 subsequent minor updates.

jQuery Major Version Usage
jQuery Major Version Usage

When you use a 3rd party dependency like jQuery you should make an effort to stay as current as possible. There is having access to new features, but you also get bug fixes and security holes patched.

Unfortunately this is not what has happened.

According to w3Techs jQuery version 1 variations dominate actual usage with nearly 83% of the sites using jQuery.

w3Tech reports the following distribution of major jQuery versions.

jQuery Major Version % Usage
1 82.8%
2 8.9%
3 8.3%

The news gets even worse, w3Techs goes on to report the most popular version is 1.12, a 12 year old version, at 54% of all jQuery sites.

What Causes jQuery Version Fragmentation?

There is no one single answer to this question as most sites will have more than one reason. Generally it is because a site feature is working and no one has paid attention to it in a while.

Often it comes down to third party dependencies, like SAAS scripts and platform plugins and themes. The later is very problematic in the WordPress ecosystem.

Many WordPress plugins are less than production quality. They are developed on the cheap without what I would call product quality testing applied. Since many developers hired to create these plugins don't keep up with modern web technology they just use what they were taught 10 years ago, which is jQuery version 1.x.

Much of the code in these dependencies is not actually developed, but rather copied, pasted and slightly tweaked. This means the developer finds something similar to what they are doing, clones the code and then makes minor modifications to the code. They just want to get the task done and unless you add a current version requirement they don't bother updating and testing against the latest.

If you have commissioned a component or plugin or any development for that matter I reccomend specifying the use of native web APIs over libraries and frameworks as these will stay current and run more efficiently. Plus you will always be current as long as your visitor has an updated browser, which today is almost always.

The proliferation of jQuery 1.x today is a product of what I call software decay. This is the neglect of production software over the years as standards and native functionality improves around the software. The failure to periodically audit and update means your software is not keeping up and will eventually break and of course lose to competition that is staying current.

Which Version of jQuery to Use?

The obvious answer is the latest, 3.4.1 at the time of this writing.

For some this might cause issues if you lean on older plugins and 3rd party plugins as they may depend on deprecated or updated functionaltiy.

This is why knowing how to code real JavaScript and knowledge of native APIs gives you an advantage.

Because most jQuery plugins are open source you can just dive in and update the code. This of course makes the code yours, which in the long run is better in most cases.

The reason you want to own the plugin code will come down to a single litmus test, does the plugin owner maintain the code?

In most cases the answer is no. It is actually a big problem in the open source world today as so many projects have simply been abandoned because the owner had no financial incentive to continue to maintain the code.

This is why I recommend clients wanting to go this route license component suites like Infragistics Ignite UI for JavaScript. Companies like Infragistics are in the business of making professional user interface components that not only make developers productive, but offer the support businesses need. Because they have a financial stake in the products they have the incentive and means to maintain and update these components.

 Infragistics Ignite UI
Infragistics Ignite UI

Before you update to the latest jQuery version you should perform a full dependency audit. Determine where plugins and other code potentially breaks. You will also need to audit any 3rd party plugins, especially in the WordPress ecosystem as many of these plugins carelessly inject a version of jQuery you don't want.

If you don't know if you do not know if your site is using jQuery or what version there is a simple code snippet you can run from your browser's console.

Determining jQuery Version
Determining jQuery Version

To access the console tool press F12 or Ctrl + Shift + i in any browser. This opens the developer tools. The console tab should be the 2nd tab, if not locate it from the list. You may need to expand the list of tabs at the end to see all tabs.

Once you locate the console tab you can paste the following snippet and hit return.



    if (jQuery && typeof jQuery !== "undefined") {

        console.log(jQuery.fn.jquery);
    }

The code first verifies jQuery exists. If jQuery is present it will then echo the value of the jQuery version. In this example the site they are using an outdated version, 1.7.2. If jQuery is not present nothing is written to the console.

jQuery That Are Now Native

jQuery made many complex things simple. As I stated web standards used this as a reference to define new standards. These are some of those features in native JavaScript.

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, https://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 https://jsPerf.com. When I have time I like to review popular tests myself to see what others have found, https://jsperf.com/popular.

Summary

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.

Share This Article With Your Friends!

Googles Ads Facebook Pixel Bing Pixel LinkedIn Pixel