News for hackers. Stuff that matters.
Re:You might not need jQuery (2014) by bichiliad on Wednesday January 13, 2021 @10:35PM (#25771555)
I think a lot of the initial appeal around jQuery was that it made querying and manipulating the DOM simple. Much of its features have been replaced by broadly-available APIs like Document.querySelector and Element.classList. Loading the entirety of jQuery just to access some of the remaining features just means you're loading JavaScript that you aren't going to use. I miss relying on jQuery because it's familiar and consistent, but it also makes it easy to forget how much better browsers have gotten in the time since it was introduced.
Re:You might not need jQuery (2014) by cosmotic on Wednesday January 13, 2021 @10:39PM (#25771591)
I thought a big part of the initial sales pitch was not having to deal with cross-browser compatibility issues.
Re:You might not need jQuery (2014) by jrumbut on Wednesday January 13, 2021 @11:51PM (#25772185)
document.querySelector was not available in IE 6 and 7.

Dealing with those versions was where jQuery really earned its spot in the JS universe. It was a lot to remember where all the quirks were and the incantations to work around them.

Re:You might not need jQuery (2014) by codeisawesome on Thursday January 14, 2021 @12:04AM (#25772317)
IE 6. Now that's a name I haven't heard in a long time...
Re:You might not need jQuery (2014) by martin_a on Thursday January 14, 2021 @03:52AM (#25773850)
Just patched a problem in a WordPress site due to (now broken) support for IE7 two days ago. The elders of the Internet are still around. ;-)
Re:You might not need jQuery (2014) by spicybright on Thursday January 14, 2021 @08:50AM (#25776204)
I'm so sorry. Do you want to talk about it? :P
Re:You might not need jQuery (2014) by martin_a on Thursday January 14, 2021 @10:14AM (#25777240)
I'm not sure. It was kind of traumatic, but on the other hand it's a very old site, so it was obvious that there might be some dead bodies in the basement. Found one, ignored the others.
Re:You might not need jQuery (2014) by jrumbut on Thursday January 14, 2021 @01:19PM (#25779962)
The IE 7 compatibility code broke the site in modern browsers, or did you really get a visitor on a Windows 98 machine?
Re:You might not need jQuery (2014) by martin_a on Friday January 15, 2021 @04:21AM (#25788709)
It was a bug in an old version of superfish.js which relied on a deprecated jQuery function to detect the browser. $.browser broke in the new(er/est) version of jQuery which is integrated in that site.
Re:You might not need jQuery (2014) by user3939382 on Thursday January 14, 2021 @06:52AM (#25775293)
The longer the better. What a neverending nightmare it was.
Re:You might not need jQuery (2014) by np_tedious on Wednesday January 13, 2021 @11:43PM (#25772127)
Maybe there was more than one big part!
Re:You might not need jQuery (2014) by arp242 on Thursday January 14, 2021 @12:40AM (#25772544)
I still think the jQuery API is significantly easier than the DOM one. querySelectorAll() returns this NodeList object that's much harder to use than it needs to be. Things like getting the next sibling is much harder than jQuery's .next(), etc. etc.

I also don't care much for the fetch() API; I dislike promises and what does it send when you try to POST a JS object ({foo: 'val'})? [object Object]. Yeah, useful...

And even in 2021-jQuery, it still works around some browser bugs and inconsistencies, even in modern browsers. Much less than it used to, but not zero either.

Re:You might not need jQuery (2014) by jarek-foksa on Thursday January 14, 2021 @04:11AM (#25773979)
With modern JavaScript you can easily cast a NodeList to an Array, e.g. `let spansArray = [...element.querySelectorAll("span")]`.

I find both `element.nextElementSibling` and `element.next()` to be examples of poor API design. The former one is more verbose than needed while the latter one is so short you can't even tell whether it's a method or a property.

Re:You might not need jQuery (2014) by porker on Thursday January 14, 2021 @04:38AM (#25774192)
> With modern JavaScript you can easily cast a NodeList to an Array, e.g.

Ah, thanks. I got bitten by this recently and didn't know what to do with this "thing that's not an array but seems like it should be, and doesn't always behave like one"

Re:You might not need jQuery (2014) by nicoburns on Thursday January 14, 2021 @05:51AM (#25774869)
FYI the reason it's not an array is because if you store a reference to it, it will stay up to date as and when the DOM changes.
Re:You might not need jQuery (2014) by jarek-foksa on Thursday January 14, 2021 @08:12AM (#25775897)
The NodeList returned by querySelectorAll() is not live. There is really no reason for it to return a NodeList other than backward compatibility.
Re:You might not need jQuery (2014) by spiralx on Thursday January 14, 2021 @06:54AM (#25775310)
Before that ES2015 allowed you to do Array.from(nodeList, mapFunc?) which I still use due to the optional mapping function e.g. Array.from(document.querySelectorAll('a'), a => a.href)
Re:You might not need jQuery (2014) by names_are_hard on Thursday January 14, 2021 @06:17AM (#25775015)
If you dislike promises, what do you prefer? Callbacks? Why?
Re:You might not need jQuery (2014) by arp242 on Thursday January 14, 2021 @06:39AM (#25775188)
Because it's a lot clearer what gets run in what order.
Re:You might not need jQuery (2014) by spiralx on Thursday January 14, 2021 @07:04AM (#25775393)
How? It's about the same if you have one callback maybe, but as soon as you have a callback within a callback - or worse, want to do something involving the results of more than one callback - I just can't see it. What's the advantage of what's often referred to as "callback hell" for you?
Re:You might not need jQuery (2014) by fatnoah on Thursday January 14, 2021 @10:49AM (#25777755)
As someone that had to handcraft client-side browser experiences in the early 2000's (think drag and drop, elements of single page applications, etc.), I basically had to write two versions of everything in order to support Netscape and IE. It was tremendously interesting because I was building things that you really didn't see out in the wild at the time. It was also tremendously frustrating dealing with DOM and feature differences.

It's hard to overstate the impact of jQuery. It more than doubled my productivity due to removal of much of the duplicated work AND the general streamlining of DOM manipulation. As someone who was also neck deep in XML and XSD, the element selection syntax also felt reasonably familiar and comfortable.

Re:You might not need jQuery (2014) by vagrantJin on Thursday January 14, 2021 @08:05AM (#25775847)
Jquery isn't going anywhere. It might take a few weeks to get a JNR dev up to speed with native dom apis. It'll take a few hours for them to grasp jquery and begin writing working spaghetti in no time at all.

> Loading the entirety of jQuery just to access some of the remaining features just means you're loading JavaScript that you aren't going to use

Isn't this the penalty for every single library we use. At most we can use about 20% and the rest is just out taking space.

Re:You might not need jQuery (2014) by runawaybottle on Wednesday January 13, 2021 @11:18PM (#25771923)
We are underselling jquery a little bit. The browsers adopted jquery’s contribution of creating one of the most intuitive ways to deal with DOM/selection. It’s similar to how JSX is probably the most intuitive solution for templating/wiring/composing at the moment, also similar to how two-way binding was incredibly intuitive.

Browsers got to this point because jquery pushed for it.