[zendaven]

I still use jQuery for frontend JavaScript when I can. It's so much more efficient than native JavaScript. I can't imagine anyone prefers to write document.getElementById('element').style.display = 'none' rather than $('#element').hide();

[jacobsenscott]

There are fewer and fewer people who know jquery, so while this might be convenient for you or me, this is just more cognitive overhead for programmers who don't know jquery. There are multiple ways to hide an element, and what does `hide()` do? Some future programmer will need to look this up, and every other jquery method they stumble across.

The main problem I have with jquery though is there's no convention for event binding, so there is literally no way to know if an element depends on a jquery event handler without grepping the js for every class, id, and data selector on the object. Even that doesn't always help. This makes it almost impossible to remove jquery from a project without breaking it.

Alpine or stimulus do a much better job of filling the event handling holes that still exist vanilla js. Dom traversal/manipulation in vanilla js is good enough, even if it isn't 100% as good as jquery.

[peterangular]

On Alpine...

I have had such a positive and lovely experience with it. It's the reactivity I've always wanted; ie plays nicely with VanillaJS without imposing a complex build process.

[SadWebDeveloper]

When you are dealing with less than 5 "interactive things", jQuery is awesome... beyond that it might be better to consider a front-end framework.

Jr devs have the tendency then to discard jquery because "is old" not because it isn't working anymore.

[Beltalowda]

I think it's not so bad if you organize things reasonably well and minimize "lemme just modify the DOM a wee bit here" hacks. jQuery was popular at a time when "cowboy programming" was very common, leading to a lot of really bad/difficult jQuery apps; but that wasn't strictly jQuery's fault, as such.

That said, front-end frameworks can of course be a better choice for many things, even if it's just because it provides this kind of organisation by default making it easier for the, ehm, less organized devs.

[dspillett]

Though for that little work, I'd rather have a small local library that implements what I need over standard DOM & JS parts instead of the full weight of jQuery.

Unless of course I need to support legacy browsers, then jQ is a no-brainer - that crap is solved there and I don't want to have to deal with it myself.

And while jQ is large compared to my little home-grown set of wrappers, it is small compared to all the other stuff many pages draw in these days, so perhaps size isn't a great metric to criticise it on!

[ulisesrmzroche]

that crap is solved in a lot of places, jQuery is no longer the only library, and you don't need to support legacy browsers as much anymore, if at all

Companies are getting more security-conscious because of all the hacks and the pain of keeping old browser support is no longer outweighing the risks of upgrading is my theory.

[psnehanshu]

There are tools like babel (even typescript) which can help you support older browsers.

[dspillett]

For personal projects I'm far beyond caring about ancient browsers. In DayJob well hopefully soon be dropping support for IE completely. Unless someone is specifically paying me to care then I don't need help supporting truly legacy UAs.

[marcolussetti]

I think the more direct comparison is

document.querySelector('#element').style.display = 'none'

That has the same ergonomics as the jQuery selector, and is just a bit longer. I feel like with editors that autocomplete, it's not enough of a difference to warrant the extra dependency.

[hbn]

I think the vanilla JS is better actually, because I actually know what it's doing.

I've never used JQuery before and would have assumed calling .hide() on an element would set the CSS attribute "visibility: hidden" rather than "display: none"

[yyyk]

>That has the same ergonomics as the jQuery selector

Nitpick: This crashes if #element doesn't exist, while the jQuery one does not. Also, the jQuery selector is a tiny bit more powerful (:even, :odd).

IMHO, jQuery is good for what it's built for - a nicer interface than vanilla - but the main use case is much less needed now that frameworks exist.

[jacobsenscott]

A but fugly, ?. helps - document.querySelector('#element')?.style?.SetPropery('display', 'none')

[MrJohz]

I don't know if that's such a good nitpick in practice. I want my code to crash if my assumptions aren't true - especially if I'm in the process of developing the code, I want to see big red errors and stack traces that point directly to the line that failed.

If it's meant to be the case that the element may or may not be present, then I'd much rather see an explicit check for that, than assume one thing and find out another later.

[zamadatix]

The same power exists, again a bit longer, :nth-of-type(odd).

[savanaly]

I would say jQuery has a place in any codebase that's simple enough it has imperative statements like that. Past a certain not-too-high level of complexity you're much better off writing "if (condition) then <element> else null" in your view and "condition = false" in your update instead of even the short $('#element').hide();.

[dbrueck]

jQuery was great in its time and still has some places where it can be a good tool for the job, but it isn't used less now because people like writing the longer form of Javascript; it's used less now because for many projects people are using frontend frameworks that let you operate at a higher level altogether.

[my69thaccount]

By "more efficient" it seems like you mean "less typing" because that is significantly less efficient in terms of downloaded code size and performance (the jQuery code calls the vanilla code.)

PS. $ is an alias for document.getElementById so you can just do $('my_id').style.display = 'none'.

[pastor_bob]

most people probably have jquery cached in their browser if you're pulling it from the google cdn

[jameshart]

Thanks to cache partitioning, this is no longer true.

See, it turns out that by carefully leveraging cached retrieval of third party resources, scripts on two different domains can figure out if they are running in the same web browser, effectively pulling off browser fingerprinting.

To stop this, modern browsers don’t share third party resource caches cross domain.

So using a well known CDN no longer confers any benefit - even if a user has pulled down jquery for another site’s benefit, when they come to your site and you request the same resource, the browser will go out and re-retrieve it, to prevent you or the third party domain from being able to infer anything about the user based on the speed of the response or whether or not the request got made.

[sensanaty]

LocalCDN is great for this! Avoids both the privacy concerns, plus makes things a bit speedier as everything is readily available locally already

[pastor_bob]

ahh wasn't aware, and good to know

[jameshart]

Indeed. We cannot have nice things.

[dbbk]

As others have mentioned this isn't the case, also the browser still has to parse that JavaScript, which for a lower end mobile phone is often significant.

[my69thaccount]

That hasn't been the case for years because of per-origin caching. CDNs get their performance from edge routing, not caching.

[mrtksn]

These days it seems like you don't touch DOM yourself anymore because it's all about virtual DOM that is managed by the framework of choice, which is probably ReactJS.

[bern4444]

Even easier:

  export const hideElementById = (elementId) => {
    document.getElementById(`#${elementId}`).style.display = 'none'
  };

Or perhaps

  export const toggleElementById = (elementId) => {
    const element = document.getElementById(`#${elementId}`);

    const newDisplayValue = element.style.display === 'none' ? 'block' : 'none';

    element.style.display = newDisplayValue;
  };

[junon]

I prefer to write the first.

[dbbk]

Does your IDE autocomplete the jQuery code though? I'd imagine it wouldn't. But it would for the native code.

[pineconewarrior]

It sure does.

But I still prefer vanilla or anything but jq

[upupandup]

but see now you are reliant on jQuery and need to figure out how to load that first.

with vanilla, it would be just typing a bunch of extra properties.

[parksy]

I am not against jQuery but if it's just verbosity then it's quite easy to:

const $ = document.querySelectorAll.bind(document)

Then later:

$('#element').whatever

I used to be a big proponent of jQuery especially in the heyday of shims and browser hacks, but in the last few years I find it often gets in the way of what I'm trying to do. Now that the native browser APIs are maturing and relatively consistent, having direct access to the objects and their properties is simply more predictable than having to second-guess a layer of abstraction that does the same job but differently.

I have to remember, what does jQuery's .hide do again? It doesn't just set display to none or visibility hidden. Give it a duration, and it will use the style attribute to manipulate the display, width, height, opacity, padding, margin, etc. Then it leaves some style properties behind. Ugh. Do I really want to do all that stuff? Do I really want to build my UI framework around jQuery so I can avoid annoying transition artefacts?

Not hating on jQuery. Just my own experience. I used to feel liberated when using it because browser APIs were so terrible but now I feel encumbered if it's included as a dependency on a project I'm forced to work with, because it does so much black box magic. If you avoid certain things and stick to what it does well then it's not bad, but then there's no point using it because what it does well is no longer a pain point in browser APIs.

For me the main thing it excelled at was DOM selection and manipulation. Native does that just as well now. The secondary benefit was animation, which these days native CSS can go a long way without excess verbosity, and if you really need a more feature rich animation library I've not come across any better than Greensock for getting the job done, even if it does have a paid tier, though I am sure there are dozens of other libraries equally suited for animation, the point is that is not jQuery's strength either.

Anyway circling back to what you were saying, efficiency-wise, for any complex animations jQuery isn't the best tool for the job. For DOM manipulation native can be just as easy with some sugar. It can do a lot of unexpected and hidden things most people aren't aware are happening, so many bugs and time wasted realising jQuery was messing with style attributes that break an otherwise well designed layout.

I would rather write a few characters more code or a couple of lines more to have direct control over what's actually happening. That seems more efficient to me.

Edit: Ok on reflection I guess I am against jQuery, but I don't hate it. Using it these days just feels like trying to figure out how to get it to do what I want to the underlying APIs, when I could more easily and predictably just be manipulating the APIs directly.