Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You might not need jQuery (2014)

youmightnotneedjquery.com

Post reply on HN
Print view View original

141–150 of 241 posts

Re: You might not need jQuery (2014)

#141

Post by names_are_hard »

arp242 wrote: post #54
bichiliad wrote: post #10

Earlier quoted context omitted.

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…

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... An…

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

Re: You might not need jQuery (2014)

#142

Post by satyrnein »

arp242 wrote: post #60
dylan604 wrote: post #55

Earlier quoted context omitted.

if the 30KB library is already cached because everyone else is using it too, then isn't it technically smaller than however many hundreds of lines of code you had to custobuild?

Most modern browsers don't really have global caches any more, and it's now all partitioned per-origin. I do agree 30k is hardly worth thinking about.

I think they are referring to loading it from a global CDN.

Re: You might not need jQuery (2014)

#143

Post by ryanbrunner »

jamiesonbecker wrote: post #45
peanut_worm wrote: post #40

Earlier quoted context omitted.

This is all very old javascript to be fair, the modern equivalents are as terse as jquery these days.

Somewhat true, but this was also old jQuery :) Even the old jQuery seems easier to read than the modern ES6 equivalent (IMO). jQuery: $(".classname").addClass("darktheme") ES6: document.querySelector(".classname").classList.add("darktheme")

Maybe a nit, but these aren't equivalent. The jQuery version will apply it to all elements that match your selector, where the ES6 version will only apply to the first matching element.

Equivalent code in ES6 would be (maybe there's a terser way but this is what I'd do at first glance):

    [...document.querySelectorAll('.className')].forEach(el => el.classList.add('darktheme'));
Not a whole lot extra in terms of actual code, but I'd argue it's not super intuitive (having to cast a NodeList to an array is a pretty big beginner footgun), and as you get into more complex scenarios, the jQuery architectural pattern of operating against collections of nodes really shines.

Re: You might not need jQuery (2014)

#144

Post by braveyellowtoad »

arp242 wrote: post #56
jart wrote: post #8

Earlier quoted context omitted.

This comment is a great example of what I call "lines of code mindset" which is form of tip of the iceberg mentality, where programmers optimize for simplicity only the code they see. Is saving 10-15 lines worth it if you need an 86.1 Kb vendor dependency? Hidden complexity you don't control is the most expensive kind I think.

It's 77k for the latest version, and after compression it's ~32k. It's really not all that large. You can also reduce this to about ~27k if you exclude some less-commonly used things like animations, shortcuts, etc. JS people be like: "86K jQuery dependency is wasteful!" Also JS people: "why do you care that an SPA loads 2M of JavaScript? Are you stuck on a 56k modem or something?"

You seem to know quite a bit about this, do you know why there isn't some sort of a "compile" phase where the jquery examples wouldn't be translated into the minimum js equivalent? Seems like then you could get the same syntax and minimum size.

Re: You might not need jQuery (2014)

#145

Post by ryanbrunner »

zhte415 wrote: post #130
jamiesonbecker wrote: post #20

Earlier quoted context omitted.

Are you being sarcastic? But, either way, it really depends. If you are writing a large application and jQuery saves thousands of lines of boilerplate, then it's totally worth it. For a tiny library (which is what this page is targeted at), then it's probably overkill and you should learn how to do it manually with pure JS. Both can be true at the same time.

May or may not be. I deal with a not small amount of customers that are on extremely slow connections where 30k less makes a big difference. You can do a lot in 30k. jQuery makes life a heck of a lot easier though.

I think this is a fair point if you genuinely want to keep your bundle size as small as possible. Many times, the people complaining about jQuery's size are serving 2 MB bundles. 30K is immaterial in that scenario.

Re: You might not need jQuery (2014)

#146

Post by catmanjan »

DarkWiiPlayer wrote: post #100
catmanjan wrote: post #79

Earlier quoted context omitted.

I've done this before - you just end up rewriting jQuery hehe.

You'd end up writing a subset of jQuery that only has the parts you need and skips those where you almost wouldn't gain anything.

Over time you end up adding just about everything back in as the app grows... But worse!

Re: You might not need jQuery (2014)

#147

Post by arp242 »

satyrnein wrote: post #142
arp242 wrote: post #60

Earlier quoted context omitted.

Most modern browsers don't really have global caches any more, and it's now all partitioned per-origin. I do agree 30k is hardly worth thinking about.

I think they are referring to loading it from a global CDN.

Yes, those aren't cached globally any more.

https://arstechnica.com/gadgets/2020/12/firefox-v85-will-imp...

https://developers.google.com/web/updates/2020/10/http-cache...

Re: You might not need jQuery (2014)

#148

Post by arp242 »

braveyellowtoad wrote: post #144
arp242 wrote: post #56

Earlier quoted context omitted.

It's 77k for the latest version, and after compression it's ~32k. It's really not all that large. You can also reduce this to about ~27k if you exclude some less-commonly used things like animations, shortcuts, etc. JS people be like: "86K jQuery dependency is wasteful!" Also JS people: "why do you care that an SPA loads 2M of JavaScript? Are you stuck on a 56k modem or something?"

You seem to know quite a bit about this, do you know why there isn't some sort of a "compile" phase where the jquery examples wouldn't be translated into the minimum js equivalent? Seems like then you could get the same syntax and minimum size.

You mean translating jQuery to "native JS"? I suppose it's possible, but I don't know if anyone built anything for it.

All I know is that you can build a custom jQuery build with grunt, as described in their README, which is what I do. I mostly use JavaScript as if the last ten years didn't happen, so I'm hardly an expert on any of this :-)

Re: You might not need jQuery (2014)

#149

Post by arp242 »

names_are_hard wrote: post #141
arp242 wrote: post #54

Earlier quoted context omitted.

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... An…

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

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

Re: You might not need jQuery (2014)

#150

Post by bryanrasmussen »

jart wrote: post #8
jamiesonbecker wrote: post #2

It's ironic that there's probably no bigger sales pitch for jQuery than this site. In every single example, the jQuery version is basically one or two lines of code, versus 10-15 lines for the alternative. (and the jQ version seems significantly easier on the eyes as well.) Also, jQuery supports promises and has for quite a while. This page hasn't aged well. I've come full circle and am now using jQuery again.

This comment is a great example of what I call "lines of code mindset" which is form of tip of the iceberg mentality, where programmers optimize for simplicity only the code they see. Is saving 10-15 lines worth it if you need an 86.1 Kb vendor dependency? Hidden complexity you don't control is the most expensive kind I think.

>is saving 10-15 lines worth it if you need an 86.1 Kb vendor dependency?

I don't actually use jQuery any more but obviously if you are using it, you are saving the 10-15 lines every time you use one of these methods, not 10-15 lines in your whole application. I have a hard time believing that the savings of code lines will not be close to the weight of the dependency in any medium sized company codebase.

Post reply on HN