The story of why I still use jQuery

When it comes to jQuery, many people say, “Just use regular JavaScript. You don't need a jQuery library. ” What can I say? I do not need many things, but despite this, it is good when they are. So is jQuery. I do not need this library, but it is definitely nice to have it at hand.

Sites like You might not need jQuery (YMNJQ) are promoting the idea that jQuery is very easy to get rid of. But the very first example on this site demonstrates a good reason jQuery to use. There, a simple jQuery line of code is replaced with 10 lines of regular JS!

Most JavaScript APIs, especially those that focus on working with the DOM, offend my aesthetic senses. This is, to put it mildly, my attitude towards them. Speaking directly, I think that these APIs are a complete nightmare. For example, the design el.insertAdjacentElement('afterend', other)certainly works. But it looks much nicer $(el).after(other). Although I never really liked the look of the function $(), it is incomparably better than what the standard APIs for working with the DOM give us. I know that instead $()you can use something like jQuery(sel)or window.jq = jQuery. But I do not program in airless space. Therefore, I prefer to use standard techniques. I don’t know whether this is good or bad, but the design has become the standard when using jQuery $().

Try to quickly remember how to get a neighbor element of another element using the DOM. What to use for this - nextSiblingor nextElementSibling? What's the difference? And which browsers support this or that method? While you are trying to remember this and look at the MDN, checking yourself, I, using jQuery, just write next()or prev().

Performing many common operations implemented in the JavaScript API is inconvenient. I could give here a whole list of such operations, but for me it was perfectly done on the YMNJQ page.

To solve various simple problems using JS tools, auxiliary functions are needed. And on the YMNJQ website, again, you can find many examples. Using jQuery is a standard way to include such helper functions in your project code. At the same time, the programmer does not need every time he needs something like this to grab pieces of code from the first answers to Stack Overflow that turned up on his arm.

Although browser compatibility problems have lost their severity these days, they are still relevant. Especially - for those who do not belong to the camp of developers who believe that if something works in 85% of browsers, then it suits them. By the way, here is the material on why Hello CSS does not use CSS variables.

Should i always use jQuery? No, of course not. Any additional dependency is an increase in the complexity of the project and an increase in the volume of its code. But jQuery is not a big library. The standard assembly, minified and compressed, takes 30 Kb. Custom assembly without ajax and rarely used features is 23 Kb. And the assembly, in which it is SizzleJSused instead querySelector, takes only 17 Kb. To solve many problems, I am quite happy with the standard assembly of 30 Kb, and the optimized assembly of 17 Kb.

Here you can see how much effort has been put into removing jQuery from Bootstrap and switching to regular JS.

The developers have written their own helper functions. They had to abandon IE support, since such support was very difficult to implement. They made the API incompatible ("we broke everything") and spent a year and a half on all of this. I can’t say that what happened is much better than what happened.

I understand the reasons for translating Bootstrap to regular JS. For example, developers want to use Bootstrap with Vue.js, or something similar. And Vue.js and jQuery in one project is already a bit of a bust. I - a big supporter of reducing the volume of unnecessary code in the web ( here and here- a couple of materials about this). But here I propose to look at the situation from a pragmatic and realistic point of view. Is the inclusion of 17 KB jQuery code in Bootstrap - is it that bad? When I say that to view sites like the Medium or New York Times you need to download more than a megabyte of JavaScript code, in order to protect this situation, they ask me if I am sitting on any 56-kilobit modem line. Megabyte JS is fine. Is 17Kb jQuery really heavy?
There are good reasons for not using jQuery. For example, jQuery is not needed if you are writing code that you want to share with others, or if you are creating some small function. But why turn inside out just so as not to use jQuery? Why all this effort if you can just write$()? I don’t think jQuery should be used everywhere and always, but I don’t think the fanatic rejection of jQuery is right.

I want to note that I am not married to jQuery. I will be happy to use something like “jQuery light” - a kind of library that covers the shortcomings of standard APIs, giving the programmer something more pleasant. The site YMNJQ recommends, among others, the bonzo and $ dom libraries , designed to solve various problems. But many of them, as it seems, have not been supported for a long time. In addition, many already know jQuery. Why change jQuery for something else without good reason?

Many readers may wonder what I, in the context of this material, can say about Vue.js, React, and other modern frameworks. But the goal of this article is to map plain JavaScript and jQuery, rather than offering the community a “Grandiose General Frontend Development Theory”.

Given the above, I believe that I can find very few reasons to use regular JS where you can use jQuery. This is mainly due to the fact that I want to create fast pages and use the simplest working constructions. At the same time, I strive to ensure that as many as possible users of the Web can view my pages. Experience tells me that the shortest way to achieve this goal are templates generated on the server, which are slightly seasoned with JavaScript in the style of "progressive improvement". If you compare such projects with something that uses something more complex, it turns out that they are often easier to develop. Such projects are usually faster, they usually have fewer errors, and while working on them, the laptop fan does not make noise that can wake the whole house.

Does this mean that modern web frameworks and powerful libraries are always bad? No, it doesn’t. Very little is worthy of always being called bad or good. But to use the framework means to make some compromises (this, of course, is true for jQuery).

In general, I see the web as an environment for viewing documents, and not something like an operating system. And the “document approach” is good not only for regular sites, but also for many “web applications” (whatever you call it).

Dear readers! Do you use jQuery?