JQuery history and heritage







jQuery is the most popular JavaScript library in the world. The community of web developers created it in the late 2000s, which led to the emergence of a rich ecosystem of sites, plug-ins and frameworks that use jQuery under the hood.



But in recent years, its status as the main tool for web development has been shaken. Let's see why jQuery has become popular and why it has gone out of fashion, as well as in what cases it is still advisable to use it to create modern sites.



A brief history of jQuery



John Resig created the first version of the library in 2005 and published it in 2006 at an event called BarCampNYC. On the official jQuery website, the author wrote:



jQuery is a Javascript library based on the motto: It should be nice to program in Javascript. jQuery takes frequent, repetitive tasks, extracts all unnecessary markup, and makes them short, elegant, and understandable.


JQuery has two main advantages. The first is a convenient API for manipulating web pages. In particular, it provides powerful methods for selecting items. You can choose not only by ID or classes, jQuery allows you to write complex expressions, for example, to select elements based on their relationships with other elements:



// Select every item within the list of people within the contacts element $('#contacts ul.people li');
      
      





Over time, the selection engine has evolved into a separate Sizzle library.



The second advantage of the library was that it abstracted the differences between browsers. In those years, it was difficult to write code that could work reliably in all browsers.



The lack of standardization meant that developers needed to consider the many differences between browsers and borderline cases. Take a look at this early jQuery source code and look for jQuery.browser. Here is one example:



 // If Mozilla is used if ( jQuery.browser == "mozilla" || jQuery.browser == "opera" ) { // Use the handy event callback jQuery.event.add( document, "DOMContentLoaded", jQuery.ready ); // If IE is used, use the excellent hack by Matthias Miller // http://www.outofhanwell.com/blog/index.php?title=the_window_onload_problem_revisited } else if ( jQuery.browser == "msie" ) { // Only works if you document.write() it document.write("<scr" + "ipt id=__ie_init defer=true " + "src=javascript:void(0)><\/script>"); // Use the defer script hack var script = document.getElementById("__ie_init"); script.onreadystatechange = function() { if ( this.readyState == "complete" ) jQuery.ready(); }; // Clear from memory script = null; // If Safari is used } else if ( jQuery.browser == "safari" ) { // Continually check to see if the document.readyState is valid jQuery.safariTimer = setInterval(function(){ // loaded and complete are both valid states if ( document.readyState == "loaded" || document.readyState == "complete" ) { // If either one are found, remove the timer clearInterval( jQuery.safariTimer ); jQuery.safariTimer = null; // and execute any waiting functions jQuery.ready(); } }, 10); }
      
      





And thanks to jQuery, developers could shift the care of all these pitfalls onto the shoulders of the library development team.



JQuery later facilitated the implementation of more sophisticated technologies such as animations and Ajax. The library has actually turned into a standard website dependency. And today it provides the work of a huge share of the Internet. W3Techs estimates that 74% of sites today use jQuery .



Controlling the development of jQuery has also become more formalized. In 2011, the team created the jQuery Board . And in 2012, the jQuery Board transformed into the jQuery Foundation .



In 2015, the jQuery Foundation joined the Dojo Foundation to create the JS Foundation , which then teamed up with the Node.js Foundation in 2019 to create the OpenJS Foundation , in which jQuery was one of the “ punchy projects .”



Changing circumstances



However, in recent years, jQuery has grown in popularity . GitHub removed the library from the frontend of its site . Bootstrap v5 will get rid of jQuery because it is its “ largest client dependency for regular JavaScript ” (currently 30 Kb, minified and packaged). Several trends in web development have weakened jQuery's position as a necessary tool.



Browsers



For a number of reasons, browser differences and limitations have become less important. First, standardization has improved. Major browser developers (Apple, Google, Microsoft, and Mozilla) are jointly developing web standards as part of the Web Hypertext Application Technology Working Group .

Although browsers still differ from each other in a number of important ways, vendors at least have a means to search and create a common base instead of a permanent war with each other. Accordingly, browser APIs have gained new features. For example, the Fetch API is able to replace Ajax functions from jQuery:



 // jQuery $.getJSON('https://api.com/songs.json') .done(function (songs) { console.log(songs); }) // native fetch('https://api.com/songs.json') .then(function (response) { return response.json(); }) .then(function (songs) { console.log(songs); });
      
      





The querySelector and querySelectorAll methods duplicate selectors from jQuery:



 // jQuery const fooDivs = $('.foo div'); // native const fooDivs = document.querySelectorAll('.foo div');
      
      





You can now manipulate element classes with classList :



 // jQuery $('#warning').toggleClass('visible'); // native document.querySelector('#warning').classList.toggle('visible');
      
      





The You Might Not Need jQuery website lists a few more situations in which jQuery code can be replaced with native code. Some developers always adhere to jQuery, because they simply do not know about the new APIs, but when they find out, they begin to use this library less often.



Using native features can improve page performance. Many jQuery animation effects can now be implemented much more efficiently with CSS.



The second reason is because browsers update much faster than before. Most of them have an “evergreen” update strategy , with the exception of Apple Safari. They can be updated in the background without user involvement and are not tied to OS updates.



This means that new browser features and bug fixes are spreading much faster, and developers do not need to wait until the Can I Use share reaches an acceptable level. They can confidently use new features and APIs without loading jQuery or polyfiles.



The third reason is that Internet Explorer is approaching a state of complete irrelevance. IE has long been the scourge of web development around the world. Its typical bugs were widespread, and since IE dominated in the 2000s and did not use an “evergreen” update strategy, its old versions are still common.



In 2016, Microsoft accelerated the decommissioning of IE by stopping support for the tenth and earlier versions, limiting itself to support for IE 11. And increasingly, web developers can afford the luxury of ignoring IE compatibility.



Even jQuery has ceased to support IE 8 and lower since version 2.0 , released in 2013. And although in some cases IE support is still required, for example, on older sites, however, these situations are becoming less common.



New frameworks



Since the advent of jQuery, many frameworks have been created, including the modern leaders of React , Angular, and Vue . They have two important advantages over jQuery.



First, they make it easy to split the user interface into components. The frameworks are designed to handle rendering and page refresh. And jQuery is usually used only for updating, entrusting the server with the task of providing the start page.



On the other hand, the React, Angular, and Vue components let you closely link HTML, code, and even CSS. As we divide the code base into many self-contained functions and classes, the ability to split the interface into reusable components simplifies the assembly and maintenance of complex sites.



The second advantage is that more recent frameworks adhere to a declarative paradigm, in which the developer describes what the interface should look like, and entrusts the framework with the implementation of all necessary changes to achieve the desired one. This approach contradicts the imperative approach characteristic of jQuery code.



In jQuery, you explicitly prescribe the steps for making any changes. And in the declarative framework, you say: “According to this data, the interface should look like this.” This can greatly facilitate writing code without bugs.



The developers have adopted new approaches to website development, which is why the popularity of jQuery has declined.



When to use jQuery?



So when should jQuery be used?



If the complexity of the project will grow, it is better to start with another library or framework that allows you to meaningfully manage the complexity. For example, to divide the interface into components. The use of jQuery in such sites at first may look acceptable, but it will quickly lead to spaghetti code when you are not sure which fragment affects which part of the page.



I have been in such a situation, when I try to make any change, I get the feeling of a difficult task. You cannot be sure that you won’t break anything, because jQuery selectors depend on the HTML structure created by the server.



At the other end of the scale are simple sites that require only a touch of interactivity or dynamic content. In such cases, I would also not use jQuery by default, because much more can be done with native APIs.



Even if I need something more powerful, I will look for a specialized library, for example, axios for Ajax or Animate.css for animations. It will be easier than loading all jQuery for a little functionality.



I think the best justification for using jQuery is that it provides comprehensive functionality for the front-end site. Instead of learning a variety of native APIs or specialized libraries, you can only read the jQuery documentation and you will immediately become productive.



The imperative approach does not scale well, but is easier to learn than the declarative approach of other libraries. For a site with clearly limited capabilities, it is better to use jQuery and work quietly: the library does not require complex assembly or compilation.



In addition, jQuery is good in cases where you are sure that the site will not get complicated over time, and if you do not care about native functionality, which, of course, will require writing more code than jQuery.



You can also use this library if you need to support older versions of IE. Then jQuery will serve you like in the days when IE was the most popular browser.



A look into the future



jQuery will not disappear soon. It is actively developing , and many developers prefer to use its API, even with the availability of native methods. The library helped a whole generation of developers create sites that work on any browser. And although in many aspects it has been replaced by new libraries, frameworks and paradigms, jQuery has played a huge positive role in creating a modern web.



If the functionality of jQuery does not change significantly, it is likely that in the next few years the use of the library will continue to slowly but steadily decline. New websites are usually created from the very beginning using more modern frameworks, and suitable jQuery usage scenarios are becoming less common.



Someone doesn’t like the intensity of obsolescence of web development tools, but for me this is evidence of rapid progress. jQuery has allowed us to do a lot better. The same is true for her successors.



All Articles