Hacker News Reader

Comment by BlameKaneda | Hacker News Reader

jQuery is still my bread and butter for DOM manipulation and events. I've found it to be much more readable than vanilla JS.

View on HN

Can you elaborate on what JQuery does for you that you can't do with modern JS features such as fetch and query selectors?

This page gives a pretty good overview of why jQuery is still relevant: http://youmightnotneedjquery.com/

Requests have gotten better with "fetch", but unfortunately, the "modern" DOM API is quite bad in some parts, making lots of stuff unnecessarily verbose. On top of that, it's really odd that the DOM API is not compatible with for-of loops, which could have been a selling point.

>it's really odd that the DOM API is not compatible with for-of loops, which could have been a selling point.

I'm not sure what you mean by that? querySelectorAll returns an iterable. Also, your link is outdated. It doesn't include the fetch API which has enjoyed wide support for quite a while now.

> I'm not sure what you mean by that? querySelectorAll returns an iterable.

Apparently my knowledge is outdated. Last time I tried to switch from jQuery to vanilla JS, the results of document.getElementsByTagName and others were not iterable with for-of.

For me, the code is easily 10x more readable than vanilla JS. And much shorter, so I can hand code everything quicker without typos.

To use an example, I'd much rather do

$(".elements").css("color", "red")

versus

var selector = document.getElementsByClassName('elements');

selector.style.color = 'red';

You can do

const $ = document.querySelector;

$('.elements').style.color = 'red';

Which is only marginally more verbose.

No you can't. $('.elements') in jQuery is more equivalent to querySelectorAll('.elements').

You can however do:

document.querySelectorAll('a').forEach(a => a.style.color = 'red')

This is the only post that I see so far that touches on the real innovation and unique value of jQuery: operating on groups. Everybody can go ahead and tell me that using a forEach every time is trivial, or that I can just insert some transpiler step in my build pipeline to take advantage of X language's convenient syntax, but the bottom line is that people use jQuery because it continues to be easier. Thank you for your insight and great design sense John Resig! Still not bested after 15 years.

Though your alias definition needs a little extra, or the function loses its context and colling it will just result ":

  const $ = document.querySelector.bind(document);

or slightly less efficient, wrap in a function:

  const $ = function(x) { return document.querySelector(x) };

or if you want to be concise and don't need to support legacy IE:

  const $ = (x) => document.querySelector(x);

(and as pointed out already, you need querySelectorAll() and a loop for what jQuery does by default, though your example will work for a single element)

The jQuery example is good, but the "vanilla" example is cleaner and simpler: the class name isn't decorated with a dot, the CSS property name is not quoted, $ might be hijacked or overloaded, it is not obvious (compared to a plain assignment) that css is a setter and what arguments it takes.

Sorry, that doesn't even work:

> document.getElementsByClassName('comment').style

> undefined

You'd need a for loop right there I believe.

jQuery has the most consistent return values I've ever seen in an API. It somehow always works. Contrasted to that the fact that a NodeList is not an Array gets me every time.

I just use vanilla JS now, but it took a while to get there.

That's 30KB over the network and 90KB of JS code in memory so that you don't need to learn about 5 standardized browser API methods that are the same in every browser going back to IE9 then. No doubt that gives you a better developer experience but I don't think your users are thanking you.

The internets users managed to live with this terrible 30k burden in the late 2000's when it was the only choice. I think probably in 2021 when 30kb is a rounding error on page sizes they can also probably manage it.

This feels like a false equivalence; how many of those 2000s users were browsing the web on mobile compared to today?

Does 30kb of js really matter on modern phones and modern mobile internet?

If "modern" means fast, then no. If "modern" means what people are using in 2021, then possibly.

This kind of thinking is why software continues to get slower and slower despite incredible advances in hardware.

Bingo. 30kb doesn't seem like much, but its easy to think it doesn't matter when viewing one dependency in isolation. But if you say "it's just x kb" to all dependencies, then you have a problem when they're all aggregated.

This is why I appreciate Svelte's take: with a compiler-heavy approach, you can have a great dev experience without saddling your users with extra dependencies.

Since many people seem to be religious today about which "packer" is the best and that using one in the first place is a necessity, the answer is apparently "yes".

I don’t follow. Is the implication here that users can identify an experience difference cause by a 30KB over-the-wire asset, or more, a 90KB in memory one? I know I certainly wouldn’t claim to have that ability myself even on low quality networks.

If you're a user on a spotty mobile connection in a rural location on a low-end device ... both.

In that case, most of the web is unusable nowadays, and jQuery is not your main problem. Maybe your argument is valid in less-developed countries where more people have spotty connections and more websites have adapted to that (but I wouldn't know, sorry).

I'm not happy about it, but the reality is that 120kB is small potatoes in the modern web world. Would it be better without, sure? But there are bigger fish to fry. If jQuery helps the developer achieve their design and development goals, that will play out better for the end-user. It's not ideal, but it's realistic.

If jQuery helps the developer achieve their design and development goals, that will play out better for the end-user.

That's not the dilemma though. Developer can build solutions without jQuery. They'll be faster, smaller, and have fewer dependencies.

Plus, if you're only using jQuery for DOM and events then it probably isn't helping you. Those are two areas where writing vanilla JS is can often be easier than writing the jQuery code to do the same job.

jQuery versus vanilla DOM is slower, larger, and adds dependencies.

jQuery versus [framework of the month] is "faster, smaller, and [has] fewer dependencies". Simpler build, too, while still keeping you from having to worry about which browser supports what.

Depends on what the most likely alternative is, then.

There are plenty of modern frameworks that are smaller than jQuery (svelte, Preact, etc). In some apps they may also be faster. If you pick svelte there's the same number of dependencies.

30kb is pretty trivial. And even so, if you are using a CDN like you should the jQuery is likely already cached on the user device.

I recall an earlier discussion on here stating that using CDN nowadays doesn't have any gains, only drawbacks.

This is correct. It's called cache partioning. https://developers.google.com/web/updates/2020/10/http-cache...

> That's 30KB over the network and 90KB of JS code in memory

A fair point, but compared to the payload of most sites (let alone apps) these days that is chicken feed.

Just opened that page itself and DevTools tells me 5.2Mb was transferred including ~175KB of JS from twitter, 65Kb JS for the video player (which seems to have 46Kb worth of css associated with it!), ~1Mb worth of font resource, ...

> so that you don't need to learn about 5 standardized browser API methods

That and the way jQuery does method chaining, which a lot of people find far more convenient, but other features. jQuery does a lot more than querySelector/querySelectorAll/friends.

> No doubt that gives you a better developer experience*

<attenborough>And here we see a forum commenter in its natural habitat, hunting the point. It sidles up slowly, and pounces...</attenborough>

(with apologies for failing to resist being facetious and slightly dickish there)

>* but I don't think your users are thanking you.*

I don't think most users will notice. Those that do due to slow connections, metered connections, low-power/low-memory devices, etc, are going to baulk at much more before even noticing jQuery on this site.

On something like HN (23.8K transferred for this page before my comment was added) 30Kb might look chunky, but few sites are remotely close to being as lean as HN.

(with apologies for failing to resist being facetious and slightly dickish there)

No apology necessary. That was funny. Because it's true. :)

Who cares when you're slurping down 40 megapixel PNGs for images that are sized with CSS to 100px x 100px?

Reply on news.ycombinator.com