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

51–60 of 241 posts

Re: You might not need jQuery (2014)

#51

Post by yashap »

gt565k wrote: post #30
dehrmann wrote: post #25

Earlier quoted context omitted.

I'm less interested in what people are running their backend on because that tends not to be where performance issues with sites lie.

WHAT? That's exactly where performance issues come from. Chances that the client side code is so poor the site doesn't load is very low.

It’s extremely app-dependent. For example, lots of heavy analytics, data crunching type apps can easily have multi-second (or longer) backend requests. For these, the BE tends to dominate perf issues.

However, for your standard CRUD type app, honestly round trips of 100-200 ms for backend requests are really common/standard. On the FE, loading and evaluating big JS bundles, rendering, etc., can be way slower. For CRUD apps I’ve worked on, perf issues on the FE have been more common than on the BE. Especially with the common React/Redux stack, it’s very easy to make perforce mistakes and end up with a lot of unnecessary component updates when things aren’t really changing.

Re: You might not need jQuery (2014)

#52

Post by jamiesonbecker »

domenicd wrote: post #44
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.

I agree this page hasn't aged well, but that's because it's stuck on IE10 as the support level it's targeting. If you don't need to target IE at all (only Edge), then everything becomes simpler. That's not always safe, but that's why you might not need jQuery... For reference: // JSON const data = await (await fetch('/my-url')).json(); // Post await fetch('/my-url', { method: 'POST', body: data }); // Request try { c…

Nice, thanks for this!

Re: You might not need jQuery (2014)

#53

Post by dehrmann »

gt565k wrote: post #30
dehrmann wrote: post #25

Earlier quoted context omitted.

I'm less interested in what people are running their backend on because that tends not to be where performance issues with sites lie.

WHAT? That's exactly where performance issues come from. Chances that the client side code is so poor the site doesn't load is very low.

I mean that it's not usually the language or the framework, but what overall interactions look like. If static HTML loads slowly, yes, it's the backend, but that's not what most sites look like these days; they're rich, client-side apps making lots of API and resource requests, not to mention overhead something like React adds.

Re: You might not need jQuery (2014)

#54

Post by arp242 »

bichiliad wrote: post #10
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.

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

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)

#55

Post by dylan604 »

onion2k wrote: post #33
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.

I would prefer web developers accepted they need to write a few hundred lines of 'ugly' vanilla JS to drive their website than they include a 30KB library that they only really use 0.2KB of. On the web, user experience should really be a higher priority than developer experience.

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?

Re: You might not need jQuery (2014)

#56

Post by arp242 »

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.

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

Re: You might not need jQuery (2014)

#57

Post by human »

I’d be careful about premature optimization. If you can write your code 2x faster by using jQuery, by all means do it. Eventually, if needed, you could rewrite your JS to be free of jQuery, but it would not be a priority for me. Dev speed if more important than load speed for me.

Re: You might not need jQuery (2014)

#58

Post by arp242 »

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

There are quite a few more examples of this:

    $('.class').remove()
    $('.class').after(...)
vs:

    var e = document.querySelector('.class')
    e.parentNode.removeChild(e)

    document.querySelector('.class').insertAdjacentElement('afterend', ...)

Re: You might not need jQuery (2014)

#59

Post by arp242 »

onion2k wrote: post #33
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.

I would prefer web developers accepted they need to write a few hundred lines of 'ugly' vanilla JS to drive their website than they include a 30KB library that they only really use 0.2KB of. On the web, user experience should really be a higher priority than developer experience.

Hundreds of lines of ugly vanilla JS which duplicate jQuery features which aren't as well tested and probably don't handle all the edge cases.

> On the web, user experience should really be a higher priority than developer experience.

Those aren't disconnected. The more time I spend on technical implementation details, the less time I have to think about UX and/or implement things that improve UX.

Re: You might not need jQuery (2014)

#60

Post by arp242 »

dylan604 wrote: post #55
onion2k wrote: post #33

Earlier quoted context omitted.

I would prefer web developers accepted they need to write a few hundred lines of 'ugly' vanilla JS to drive their website than they include a 30KB library that they only really use 0.2KB of. On the web, user experience should really be a higher priority than developer experience.

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.

Post reply on HN