Ben Halpern

Posted on Nov 11, 2019

Who still regularly uses jQuery?

#javascript #jquery #webdev #discuss

Lots of us are still using it for one reason or another. How about you? What's your story?

Top comments (98)

Sandeep Balachandran • Nov 11 '19

Vince Ramces Oliveros • Nov 11 '19

One word. "Legacy"

jQuery shines the medieval era of web development.

Fernando Crozetta • Nov 11 '19

medieval era of the web development.

This is the most accurate way to describe those times.

Eddie • Nov 11 '19

Too many people are so eager to jump on the jQuery hate bandwagon. I'll say it - I STILL USE JQUERY.

Why?

Some of my users are still on IE11
Reduction in keystrokes
Easier to implement drag, drop, and sortable
I currently do not use a JS framework

With that said, I do use it sparingly and when I do, I make sure to indicate that a variable is pointing to a jQuery object:

$menuItems = $('.menu-items');

Dmitrii Pashutskii • Nov 12 '19

At least the first point you can change with Babel :)

Dylan Davenport • Nov 11 '19 • Edited

I still use JQuery for all of the same reasons 😅 I work at a non profit that caters to an older demographic so IE support is a necessary evil.

Anthony Bouvier • Nov 11 '19

Yup.

Cause not all of us over-engineer things by applying React or Angular to every bespoke 4 page website.

We have clients that are restaurants, bookstores, ad agencies, and otherwise and if you build out a 10 page website for any of those and decide setting up a complex frontend build system somehow makes sense for them, boo on you.

BootStrap 4 is super popular (and v3 still actually). It includes jQuery.

WordPress powers an insane # of websites and jQuery is included by default.

I've said it here many times in comments: you better have a great reason for choosing one of those frameworks. Otherwise, you're over-engineering and making a poor choice.

There are more websites/webapps that don't need those than there are that do need them.

Alan Dávalos • Nov 12 '19

I would agree that if anything the point of removing JQuery is because you can do most of that stuff with just vanilla JS, not that you need to begin using a framework

As you mention, using a JS framework for every static 4 page site is overkill, but adding a 30kB library when you can make without it is still plenty overkill IMO

There's a good reason why Bootstrap 5 is ditching JQuery 5 and just using plain old JS ;)

Anthony Bouvier • Nov 12 '19

I do agree with you on removing jQuery to replace things with vanilla js. I'll never argue against that unless you still have to support IE11 (and I happen to need to because on some sites I deal with I still get upwards of 10% of my visitors coming from IE11).

But: 30kb, what ever will we do in comparison to what gets downloaded with React/Vue/Angular and whatever monstrous sized files webpack creates?

Yet the state of front end dev right now will download 100+kb in fonts and let's not even talk about the image size people put out right now.

Or the friggin' ad network includes, trackers, analytics, etc.

There are a dozen other things to fix first in optimizing front end web page total download size than a single library. The average web page size in 2010 was 702kb compared to in 2016 which is 2232kb.

jQuery's size is hardly the problem. :)

Holy-Elie Scaïde • Nov 12 '19

Yeah, but jQuery and the like are very readable and consistent. Sometimes, jQuery may be too heavy, that's why I used a smaller framework for dom manipulation. But if it's there or there's no bandwidth issue, jquery it is.

Dian Fay • Nov 11 '19

I'm using it in new development right now and there's nothing you can do to stop me!

Dmitrii Pashutskii • Nov 12 '19

But, why?? xD

Dian Fay • Nov 12 '19

It's a traceability and logistics platform using event sourcing in Postgres to maintain manufacturing, siting, and troubleshooting histories. The database and backend API are the important parts, while the web application is only one of several points of interactivity or interoperability. And releasing a functioning piece of software was/is more important than keeping up with the client-side Joneses, so to speak: this is essentially a one-woman production, and I don't have time to get as good with newer frontend techniques as I am with the stuff I've been working with since last decade. jQuery, server-rendered templates, and REST did the job well enough then and they do the same now!

Anthony Bouvier • Nov 12 '19

Spot on. :)

Dmitrii Pashutskii • Nov 13 '19

But to learn jQuery and check its documentation is much harder (in terms of time spending) than just use the Programming Language itself - JavaScript.

You don't need to learn any of modern techniques, you just need to know how to use the language without additional abstractions.
There is still the cases where doing something with JS harder than jQuery, but not so many.

I recommend to check youmightnotneedjquery.com/

Dian Fay • Nov 13 '19

Everything you've said is true! However, I do not need to learn jQuery, having learned it many years ago, and practically never need to reference its documentation since I'm not doing anything fancy with it. I am aware of document.querySelector and other such native functionality having become more generally available. I've used some of it in other projects where I was working with other people who knew this stuff well enough to make the call that we could do everything we needed without jQuery and ignore browsers that couldn't keep up.

I am not those people. This project might not need jQuery -- I would go so far as to say there's a good chance it doesn't -- but I'd much prefer to be consistent about using jQuery than the alternative.

Bulama Yusuf • Nov 21 '19

Hahahahaha... This one got me.

newbie • Sep 17 '20

I'm learning Jquery in 2020! Hmmm..YEAH!

Jack Harner 🚀 • Nov 11 '19

I use it. 🙋‍♂️

Most of my work lately has been in WordPress and jQuery is built in.
$("#id") is easier to type than document.getElementById("id").

While I'm still learning more and more about React, I plan on eventually figuring out the setup for a React Frontend with a WordPress backend. Frameworks like Frontity make that connection a whole lot easier.

Alan Dávalos • Nov 12 '19

If you really just love $() you can add this line to your JS

const $ = selector => document.querySelector(selector);

or this one if you don't want to compile to es5

function $(selector) {
    return document.querySelector(selector);
}

And remove JQuery as it's overkill to have your user download a whole library if that's all you want XD

Aaron • Nov 13 '19

Thats a great tip Alan! I agree that it is overkill and I haven't used it for a number of years. I think when I stopped using it I became a better developer and got a much better understanding of js.

Mateus Vahl • Nov 17 '19

const $ = document.querySelectorAll.bind(document)

Paweł Kowalski • Nov 11 '19

Fun fact

If you need to access element via ID, then you can skip functions altogether.

Having element: <div id="my-element"></div> you can access it via window["my-element"] ;-)

Eugene Karataev • Nov 12 '19

It's not always safe to use this trick to query an element. For example, if you have <div id="alert" /> on a page, accessing window['alert'] will not return the element you're looking for.

Jack Harner 🚀 • Nov 11 '19

That is a fun little fact.

Good to know!

Daan Wilmer • Nov 12 '19

I think your first reason is the main cause of that eighty-something percentage of websites. There is a huge number of websites based on wordpress, and they all have jQuery.

I personally write a mix of vanilla JS and jQuery when writing javascript in wordpress. In most cases I prefer vanilla JS, but sometimes jQuery just has features ready that I need and... it's just there, you know?

Amanda Iaria • Nov 11 '19 • Edited

The past 6 months I've been not been using it when I'm not coding in a framework. A lot of things that I thought would be easier aren't that bad in es6.

Though $(selector) will always be nice ... I really don't like the document.querySelectorAll(blah).forEach((eachselector) = { so much for something small });

blah

Paweł Kowalski • Nov 11 '19 • Edited

This is how my utility looks like for that:

const $ = (s, p = document) => {
  if(/object HTML.*Element/.test(s.toString())) {
    throw new Error('[utils/dom/$] Passed dom element instead of selector (string).');
  }

  return Array.from(p.querySelectorAll(s))
};

export default $;

I even export it as $ because i got so used to it ;-)))

I should note that it always returns an array, so no matter if it returns one element or multiple, you can still have one code to iterate matching elements. And if you need only one because you know there will be only one, [0] saves the day, just like in jquery unwrapping method.

Maximillian Heth • Dec 10 '19

That's pretty nifty!

I made a slight adjustment that will save you the trouble of having to add [0] to the array if there's really only one instance of that selector.


const $ = (selector, context = document) => {

  if(/object HTML.*Element/.test(selector.toString())) {

    throw new Error('[utils/dom/$] Passed dom element instead of selector (string).');

  }

  if (context.querySelectorAll(selector).length > 0) {

    return [...context.querySelectorAll(selector)];

  } else {

    return context.querySelector(selector);

  }

};

Paweł Kowalski • Dec 10 '19

I had it in previous version, but i value having returned array much more than this. Because i often map, i can safely map over array of one element, but it would throw if i dont have it inside the array. Im huge advocate of that.

merlijn van lent • Nov 11 '19

To be honest, I have no idea if this is an good idea but...

window.$$ = (selector) => {return document.querySelectorAll(selector);};

Does save a lot of keystrokes on an daily basis and because of the double $ most people would at least think of jQuery and thus that it is some sort of selector.

Aimeri Baddouh • Nov 12 '19

I saw a talk by Wes Bos at JAMstack conf where he did exactly this. Actually he implemented $ for querySelector and $$ for querySelectorAll

I think this is a pretty neat trick, but there's a part of me that always wants to pause and analyze whether it is strictly necessary to expand on the window object needlessly. Do you have any opinions on setting this as a part of the window object vs using a separate function to do this?

Daniel Lo Nigro • Nov 11 '19

You can always just make your own function called $ :)

Ryan Smith • Nov 11 '19

I use it on a legacy client application. It still works and there isn't a huge benefit from trying to replace it. There are much bigger issues to address with the application before trying to replace jQuery. I try to promote using plain JavaScript on newer development in the project but some developers are more familiar with jQuery, which is okay. Even though JavaScript has caught up to jQuery, I still think jQuery's syntax and functions are more convenient to use.

Ethan Hampton • Nov 11 '19

Precisely my situation. There are many, many other things I would want to improve in the application I am working on before I even think about touching something that although old, still works just fine

Aaron • Nov 13 '19

Im glad you are taking this practical approach. I think you should always prioritise improving the product functionality for the user over refactoring the code for the sake of it. Keep up the good work

Anurag Hazra • Nov 11 '19

Please also add #jokes tag

Adebowale Ayodeji • Nov 14 '19

When people see some set of new tools, they always forget the good part of the former, and will be blindfolded on the bad part of the later.
As for me, even though I'll ditch jQuery for vue on big projects, jQuery is still ok for some reasons.

Supporting IE, the default browser of windows 7 is very important.
When you use a cdn, the 30kb pain is gone.
It's very cool to replace selectors, but when you try replacing the $.ajax, $('#id').show(), .animate, etc with plain JS, you're really stressing yourself just because "You don't wanna use jQuery"!
Even without any JS knowledge, you can still edit jQuery code (I know what I'm saying!), and approximately every web developer understands jQuery. jQuery's age or modern JS should not judge whether you need a framework/library or not, your project should be the judge! I only wish folks from envato and the likes are here...

View full discussion (98 comments)

Some comments may only be visible to logged-in visitors. Sign in to view all comments.

DEV Community

Who still regularly uses jQuery?

Top comments (98)

Read next

EchoAPI vs Bruno: A Comprehensive Comparison from Design to Testing 💡

How to Create a WhatsApp Chatbot Using WhatsApp API in Laravel

How PDFs Can Enhance Collaboration in Remote Work

Zero-Downtime PostgreSQL Migration: My Journey with DevCycle 🚀