In my professional life, I use jQuery daily, in my personal projects, almost never. BUT that doesn't mean jQuery doesn't have certain niceties that plain-old javascript doesn't. But implementing them in modern javascript is only a few lines of code, so I end up with my own micro-jquery usually by the end of a project, because I will implement a feature from jQuery I like that doesn't exist (or at least, that I don't know about).

I usually do something like:

    const $ = function(selector) { };

at the start of every project, implement document.querySelectorAll, then return an object with a handful of functions like on(event, callback), off(event), one(event, callback), attr/data/prop(name[, value]).

All of them are basically just tiny <10 LOC shims for a lot of built-in functionality. But that way I still get the niceness/terse-ity of jQuery, but not the bloat and overhead of it being able to still do:

    $('.selector').one('submit', () => false)

is a lot nicer than

    document.querySelector('.selector).addEventListener('submit', () => false, {once:true}).

jQuery is a few kilobytes not some huge libruary. You can do it n pure js but jQuery allows you to do it in less lines of code and cleaner.

There are only a few cases where that's true today. Probably 90% of the functions that helped a lot before have been implemented by browsers natively today.

So? The jQuery code still works regardless of when the browser decided to catch up.

I picked up jQuery because JS in browsers weren't cross-compatible for ages. I don't see a need to stop unless jQuery stops being cross-compatible.

> So? The jQuery code still works regardless of when the browser decided to catch up.

So, it's not needed anymore. I also started using jQuery in order to get cross-browser support for handy stuff, but since that stuff is now cross-browser without using any 3rd party libraries at all, there is no need to use extra bandwidth and CPU cycles from your users to download something that basically already exists.

Most of the world's bandwidth is being used to stream Netflix and Youtube. I think the web will be OK if my site sends a network request for an 87KB script every now and then.

I never undertood the fuss with bandwidth and jquery either... it's only 30k once behind mod_deflate. To put it in perspective, vue.global.js is 463k or 104k once gzipped.

There are many reason not to use Jquery for greenfield projects now, but bandwith is not one of them.

The "fuss" is not about the specific numbers of bandwidth but more the mindset of not using more resources than absolutely necessary. And yeah, my breed who seems to care about this seems to be scarcer and scarcer out there but I promise, we still do exists.

Funny how some people have this mindset only about jquery and not unecessary fonts, icons, image backgrounds, etc.

When have I argued that? Or are you putting other people's opinion and saying I hold them?

Where did I say it was you ?

Made a mostly minimal status page app thing for some services based development and ripping out the jQuery used during prototyping cut the total load by almost half. There are some use cases where skipping even small but unnecessary inclusions can make a measurable difference.

Still preferable over how most SPAs are written these days, especially when looking at overhead.

jQuery was a browser normalization layer and one heck of an API for DOM manipulation.

The first is thankfully not needed anymore, the second hasn’t been matched in simplicity and power by the native one, unfortunately. Not by a long shot.

If you don’t believe me, check out one of the “You Might Not Need jQuery” sites. They read much like “you might not need firelighter, stones and sticks are all you need”.

to be honest, I don't use jquery either, but https://youmightnotneedjquery.com/ seems to be telling me that I might just need jquery if I want the code to be concise and readable.

EDIT: oh, I just realized that's exactly what you were saying!

Yeah, I always find it hilarious that it ends up showing that you may not need it but it sure is nice to have.

It's at 87KB these days for the minified production version. There are corporate logo PNGs that are bigger in size.

That's larger than all of the JS business logic in most of my applications and comparable to some of my stylesheets. For mobile users it all adds up, and not everybody has fantastic reception all the time.

You're not wrong about logos, but I find that webp will often squish that sort of thing down to 10-15k.

GP isn't saying you should use React, they're saying that if you don't need React you probably don't need jQuery either and you might as well just use pure Javascript. Most of the functions people used jQuery for are natively supported in every major browser that runs Javascript, and the few that aren't have decent polyfills.

I mean, let's be real; most of what people were using jQuery for was stuff like `querySelector`, `closest`, `classList`, etc... For those people, pure Javascript is JQuery now. If you don't want a framework and you don't want reactive/declarative interfaces, then you probably don't need a library.

I would say the same thing (maybe to a lesser degree) about "standard" libraries like Lodash. Native Javascript has a `reduce` function now, it's widely supported. And if you have to target any of the very few browsers that don't have it, then polyfilling is (usually) the better choice. See also Blueberry and promises; just use JS promises, they're fine.

bluebird?

Yep, good catch :) It's been a while since I ran into it.