jQuery is completely unnecessary now, you can use the built in element selectors to do all the same stuff without pulling a huge lib in. The value in jQuery was acting as a shim to smooth over IE's deficiencies back in the day. Now, its a waste of bandwidth.

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

yeah, I'm very glad that we have a dozen and a half Javascript libraries that aren't jQuery instead!

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.

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.

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.

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}).

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.

Few days back I became aware of youmightnotneedjquery.com so we can even do away with jquery.

I agree. There is no bandwidth wasted when using a popular CDN just drop it in and enjoy the simplicity it still ads to the already nice as well JavaScript methods.

It's fine if you don't want to call it a waste of bandwidth, but bandwidth is definitely still used because browsers don't share caches between domains https://www.stefanjudis.com/notes/say-goodbye-to-resource-ca....

Silly point as jQuery is a few kilobytes meanwhile your custom font is a few megs.

It’s not a silly point. It’s clarifying a misconception that was long used as an argument for using CDNs to deliver script assets like jQuery, which was being repeated here in context.

I feel like if you are worried about 30kb, you're probably also not using custom fonts; or you're at least not blocking rendering behind them (you're accepting FOUT).

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.

You're making the assumption that the developer has any input in the matter.

In which case it makes even less sense for someone to complain about reducing Javascript bloat just because a web font that a developer doesn't control and doesn't have any input over exists.

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.

Whether or not there is shovelware in frontend development is irrelevant: jQuery provides little to nothing over regular vanilla JS nowadays.

I really enjoy using alpine.js. It gives me dead-simple lightweight DOM manipulation with much less code than vanilla JS or jQuery and doesn't require any build systems.