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

181–190 of 241 posts

Re: You might not need jQuery (2014)

#181

Post by idkwhoiam »

joshxyz wrote: post #96
halis wrote: post #23

Having used react and redux for several years now, I'm a bit burnt out on how bloated and silly the entire front end has become. If I could decide for myself, I probably would use raw DOM or jQuery at this point.

I did the following, still comfy with react. - Got rid of redux because it's shit - Got rid of Material UI because it's bulky and its API changes are painful, replaced it with tailwind - Got rid of React Router because it's bulky and its API changes are also painful, replaced it with a simple hook

How did you replace Material UI with Tailwind? You mean you reimplemented all the components it ships with?

Re: You might not need jQuery (2014)

#182

Post by peanut_worm »

ryanbrunner wrote: post #143
jamiesonbecker wrote: post #45

Earlier quoted context omitted.

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…

NodeLists should have a forEach method as far as I know

Re: You might not need jQuery (2014)

#183

Post by spicybright »

martin_a wrote: post #102
codeisawesome wrote: post #47

Earlier quoted context omitted.

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

Re: You might not need jQuery (2014)

#184

Post by necovek »

arp242 wrote: post #82
varrock wrote: post #73

Earlier quoted context omitted.

I just want to mention that you are replying to someone who never said anything about SPA. They made an interesting point about trade offs.

It describes the general attitude of the community; go to /r/javascript or /r/webdev and mention jQuery (...if you're brave enough) and you'll get those kind of responses, often accompanied that you should be using "modern tools". Then mention multi-megabyte JS bloat and you'll get those kind of responses as well, in the very same thread, and the very same people will be argueing both points at the same time.

While your points might be true, you are arguing how there are hypocritical and dishonest people somewhere else.

You are also putting a heavy burden of proof on your readers: it generally sounds implausible that exactly the same people would complain about 1MiB not for the same use-case, but I am not going to go and fact-check that (with the implausibility of the claim, I would expect you to give direct pointers yourself or will simply distrust your claim).

Re: You might not need jQuery (2014)

#185

Post by mad182 »

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

The size argument against jquery has always dumbfounded me. Bundle sizes in megabytes, "node-modules" folders with thousands of files and hundreds of megabytes are fine for modern web apps, but if you dare to mention jquery, you can bet someone will cry about overhead and waste.

Re: You might not need jQuery (2014)

#186

Post by [deleted] »

franciscop wrote: post #78
skynet-9000 wrote: post #74

Earlier quoted context omitted.

Very nice, and great site design too. (BTW, the baggage of supporting old versions of IE was removed when jQuery 2 was launched in 2013. There's now also a "slim" jQuery that removes a few features for a smaller file size.)

Thanks! But jQuery has not really moved over, compare "addClass" in jQuery vs UmbrellaJS: - Umbrella 6 lines (max col 55): https://github.com/franciscop/umbrella/blob/master/src/plugi... - jQuery 35 lines (max col 83): https://github.com/jquery/jquery/blob/master/src/attributes/... Yes I reuse methods there to make my life easier like `.eacharg()`, but jQuery as well with `getClass()`. The difference is that Umbrella…

[deleted]

Re: You might not need jQuery (2014)

#188

Post by notjustanymike »

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 never just 10-15 lines, and I'll always take 86Kb of a properly tested, production environment validated, properly documented, community supported, cross-browser library over the one-off functions I frequently squash in code reviews.

Re: You might not need jQuery (2014)

#189

Post by GlitchMr »

mdtrooper wrote: post #113
domenicd wrote: post #44

Earlier quoted context omitted.

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…

Really thanks, but Android Chromium has support "fetch" too late (2020). Well, I can wait.

You can use a polyfill such as https://github.com/github/fetch.

Re: You might not need jQuery (2014)

#190

Post by joshxyz »

idkwhoiam wrote: post #181
joshxyz wrote: post #96

Earlier quoted context omitted.

I did the following, still comfy with react. - Got rid of redux because it's shit - Got rid of Material UI because it's bulky and its API changes are painful, replaced it with tailwind - Got rid of React Router because it's bulky and its API changes are also painful, replaced it with a simple hook

How did you replace Material UI with Tailwind? You mean you reimplemented all the components it ships with?

Well that's just impossible. What I just noticed was that when I looked deeper on MUI components, their internals are bulky and almost always used a mixed of JS & CSS instead of just CSS. They even import an external library for their styling.

On low-end devices it's a bit too much (I'm talking about edge-case users with phones as cheap as $50). It was also quite a chore keeping up with their API changes every couple months.

I forced myself to cut down on components and just style my UI with CSS. It's more consistent, more predictable, and less strain on the end-user's device. It's a trade-off across looking good, better end-user performance, good user experience, good developer experience, and having more time for the product and users instead of maintaining and updating dependencies.

Post reply on HN