Hacker News Reader

Comment by bichiliad | Hacker News Reader

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.

View on HN

I thought a big part of the initial sales pitch was not having to deal with cross-browser compatibility issues.

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.

IE 6. Now that's a name I haven't heard in a long time...

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

I'm so sorry. Do you want to talk about it? :P

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.

The IE 7 compatibility code broke the site in modern browsers, or did you really get a visitor on a Windows 98 machine?

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.

The longer the better. What a neverending nightmare it was.

Maybe there was more than one big part!

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.

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.

> 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"

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.

The NodeList returned by querySelectorAll() is not live. There is really no reason for it to return a NodeList other than backward compatibility.

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)

If you dislike promises, what do you prefer? Callbacks? Why?

Because it's a lot clearer what gets run in what order.

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?

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.

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.

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.

Reply on news.ycombinator.com