It's used out of convenience, and avoiding errors. jQuery selectors are stupidly simple to do complex stuff with. I just wish they had a jQuery.selector distribution.
These guys need to get over themselves. JQuery provided a really nice way for designers to copy/paste effects onto web elements. And then they took it way, way too far, to the point where whenever I see a "new JQuery plugin to do X" I just look the other way.
JQuery just gets in the way these days.
$("#element") is an anti-pattern. That code should just return the DOM node, not some silly object with unknown attributes. We're way past the point where you need to abstract the entire document object model, and I argue you should never have done that to begin with.
Being able to select something, then chain operations on those nodes is really where jQuery shines, IMO. All of the non-DOM stuff (e.g., AJAX) is fine with vanilla JS these days.
> Concatenating a bunch of things together to make a selector
This is semi-valid and using the jQuery.filter() function helps a bit. Overall though, it's not a huge problem, IMHO. Just put together the selector incrementally. Likely you need bits of that selector elsewhere anyways.
> Going over the top with chaining
I've written some complex code using jQuery and none of it had a chain as long as your example. Still don't see how this is jQuery's fault.
> Not caching collections
Then cache them. How is jQuery preventing you from doing this?
> HTML
This is just runs faster. When performance is critical, I find it acceptable to do this.
What I have seen of jQuery falls into two camps, people who use it instead of basic DOM code like document.getElementBy Id, and horrible ungodly spaghetti code.
Funny how all the jQuery fanboys are quick to downvote, question my knowlege, and ignore my question simultaneously.
jQuery still lacks the ability to select for just a single element. That makes it horribly inefficient for id selectors among other single-element cases.
"It doesn't force you to program or organize your code in a certain way"
Yes it does. JQuery calls it "new wave JavaScript", but really it's just an anti-pattern. JQuery forces you to select all elements using $() before being able to use any of the methods. And you have to call $().get(0) to get the
selected element out. It is this unnecessary process that
gets very tiresome. Let's see if this makes it more clear:
$('#elm').color('red');
/* do some stuff here */
$('#elm').text('new text');
To simplify that (and not require a redundante DOM call) you'd use a local variable to store a reference to the element:
var d = $('#elm').get(0);
$(d).color('red');
/* do some stuff here */
$(d).text('new text');
I argue that this is unnecessary when you could just write conventional code instead:
var d = document.getElmentById('elm');
d.style.color = 'red';
/* do some stuff here */
d.innerHTML = 'new text';
The way the $() function operates just doesn't sit well with all coders, regardless of how solid JQuery is in other respects.
"Useless" is subjective, but the jQuery object does a lot of extra work above the vanilla example.
$ isn't just a syntax layer on top of querySelectorAll. When you do $('p'), it first queries the DOM for everything that matches that selector, then it creates new jQuery objects to wrap each of the returned nodes as well as creating a jQuery object to contain them.
If all you're doing is setting the innerHTML of these objects, it's a non-trivial overhead.
IIRC jQuery started out using string parsing to achieve this but its widespread use prompted browser vendors to add the document.querySelector and document.querySelectorAll methods to their browsers.
Probably in older browsers it still uses the old method but for modern browsers it just passes [selctor] in $("[selector]") through document.querySelectorAll; no string parsing necessary.
jQuery uses getElementsByID, getElementsByClassName etc. when available in the browser. There is only a small overhead in parsing the selector to see if it's e.g. a simple ID or class selector.
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.
var elemt = $('#elementID')
and then you can call something like elemt.hide() or whatever.
reply