We are, indeed, in a world where Jquery is now the preferable choice. Frontend development is going through what video games went through in the 80s, so much new shovelware every day that people are eventually going to get tired of it.
I usually do something like:
const $ = function(selector) { };
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)
document.querySelector('.selector).addEventListener('submit', () => false, {once:true}).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, 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.
There are many reason not to use Jquery for greenfield projects now, but bandwith is not one of them.
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”.
EDIT: oh, I just realized that's exactly what you were saying!
You're not wrong about logos, but I find that webp will often squish that sort of thing down to 10-15k.
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.
It's a reasonable argument to make that minimizing 3rd-party library use is premature optimization for most websites, but if you get to the point where you need that optimization then it is 30kb and it won't be cached (CDN caching is a myth, CDNs are only useful for minimizing server load/response-time they aren't shared between domains) and it will block your initial app logic.
I am sympathetic that worrying about 30kb is overkill for a lot of apps. But if you are in a position where you're really optimizing for speed to the point where even megabytes matter, then those 30kb are not cached and they block page logic from executing until they're downloaded. And that remains true even if there's another performance change that would be higher impact that you're not allowed to make.
If anything, being not allowed to reduce asset size for your website would make efficient JS bundling matter more, since it's one of the few resource bundles you'd be allowed to do something about and it would be pulling double-duty to try and slightly cover for the inefficient fetches that you can't change.