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();
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.
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.
Jr devs have the tendency then to discard jquery because "is old" not because it isn't working anymore.
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!
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.
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.
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.
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"
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.
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.
PS. $ is an alias for document.getElementById so you can just do $('my_id').style.display = 'none'.
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.
export const hideElementById = (elementId) => {
document.getElementById(`#${elementId}`).style.display = 'none'
};
export const toggleElementById = (elementId) => {
const element = document.getElementById(`#${elementId}`);
const newDisplayValue = element.style.display === 'none' ? 'block' : 'none';
element.style.display = newDisplayValue;
};But I still prefer vanilla or anything but jq
with vanilla, it would be just typing a bunch of extra properties.
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.