Who still regularly uses jQuery?

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

Comments

[Sandeep Balachandran]

[Vince Ramces Oliveros]

One word. "Legacy"

jQuery shines the medieval era of web development.

[Fernando Crozetta]

medieval era of the web development.

This is the most accurate way to describe those times.

[dataPixy 🧚‍♂️]

last time I used it & d3.js 🤣🤣🤣

RandomFractals / droneStrikes

Data viz of US drone strikes in the Middle East

droneStrikes

Spatial Data Viz of U.S. drone strikes in the Middle East

dronehits.herokuapp.com/

Graph View

Data View

View on GitHub

[Anurag Hazra]

Please also add #jokes tag

[dataPixy 🧚‍♂️]

👎👎👎

[Holy-Elie Scaïde]

Not regularly, but I have use jQuery. Mainly where I have a simple web app (A few pages without much logic in them, just showing some content). Going with React would be too much a hassle (You have to maintain consistency within the global state). And the few times I had to work on a Wordpress site (I guess they are why jQuery still have this usage)

[Willane Paiva]

I use it on daily basis, cause of my current job.

[Amanda Iaria]

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

[merlijn van lent]

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]

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]

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

[Paweł Kowalski]

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]

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]

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.

[Vicente G. Reyes]

What's jQuery?

[Dian Fay]

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

[Dmitrii Pashutskii]

But, why?? xD

[Dian Fay]

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]

Spot on. :)

[Dmitrii Pashutskii]

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]

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]

Hahahahaha... This one got me.

[newbie]

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

[Daniel Schulz]

I refactored a jQuery project to vanilla a few weeks ago.
Working with e-Commerce software has you using jQuery frequently as well. The ecosystems of Magento and Shopware for example have deep roots in jQuery.

Also, there's still a reason for jQuery. Sometimes, it fits just right into a project. Especially medium sized projects that are not expected to grow a lot could benefit from a smaller bundle size compared to what babel and webpack wrap up sometimes.

trash bandicoot

@freezydorito

the worst aspect of jquery is that the ‘platform’ ‘caught up’ to it and that has inspired people to really think hard and pretend they don’t need anything that’s not the barebones standard library to build websites

11:52 AM - 10 Nov 2019

0 13

trash bandicoot

@freezydorito

i’m putting scare quotes here because by ‘caught up’ what i mean is that we started having to use a more hella verbose syntax that then babel converts to legacy javascript at a bundle cost that’s potentially higher and less manageable than the what 2kb that jquery is

11:53 AM - 10 Nov 2019

1 7

Also, what even is a legacy codebase? Lots of small business pages are made well before 2015, when es6 was finalized. For most pages it's just not feasible to adapt a new codebase every 5 years, hence Bruce's "shocking" statistics. I wouldn't call jQuery based projects "legacy" for the sake of jQuery.

[Ryan Smith]

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]

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]

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

[Eddie]

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

Why?

1. Some of my users are still on IE11
2. Reduction in keystrokes
3. Easier to implement drag, drop, and sortable
4. 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');

[Dylan Davenport]

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.

[Dmitrii Pashutskii]

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

[Manuel Ojeda]

Only for Bootstrap, thats all 😅