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

121–130 of 241 posts

Re: You might not need jQuery (2014)

#121

Post by porker »

jarek-foksa wrote: post #109
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…

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"

Re: You might not need jQuery (2014)

#122

Post by realityking »

arp242 wrote: post #58
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")

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', ...)

This is good example of how browser APIs have gotten better:

// Edge 12 document.querySelector('.class').remove();

// Edge 17 document.querySelector('.class').after(...);

Where jQuery shines - but also hides a lot of complexity- is when operating on an array of elements, e.g. if you want to remove all elements with a certain class.

Re: You might not need jQuery (2014)

#123

Post by BigJono »

lmm wrote: post #48
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.

> Is saving 10-15 lines worth it if you need an 86.1 Kb vendor dependency? Yes, absolutely. That's a total no-brainer. > Hidden complexity you don't control is the most expensive kind I think. There's oodles of hidden complexity you don't control in any modern CPU, but most developers (rightly!) don't care. Complexity you have to fix bugs in is the expensive type, but IME you're far more likely to hit bugs in your cu…

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

> Yes, absolutely. That's a total no-brainer.

Are you taking the piss?

Re: You might not need jQuery (2014)

#124

Post by porker »

petecooper wrote: post #92
lmm wrote: post #48

Earlier quoted context omitted.

> Is saving 10-15 lines worth it if you need an 86.1 Kb vendor dependency? Yes, absolutely. That's a total no-brainer. > Hidden complexity you don't control is the most expensive kind I think. There's oodles of hidden complexity you don't control in any modern CPU, but most developers (rightly!) don't care. Complexity you have to fix bugs in is the expensive type, but IME you're far more likely to hit bugs in your cu…

>> Is saving 10-15 lines worth it if you need an 86.1 Kb vendor dependency? >Yes, absolutely. That's a total no-brainer. I'm curious - would you be able to elaborate, please? Thank you.

Assuming I'm going to need the complexity more than 1-2 times in my source code, I'm going to be writing my own abstraction. Which takes time, needs tests writing, and I am going to make a typo or other silly mistake somewhere.

Run into a couple of examples of such complexity, and the dependency is well worthwhile.

A jQuery that can be tree-shaken would be awesome, as there are parts I use regularly and others I have never used. Ironically the -lite bundle leaves outs parts I use frequently...

Re: You might not need jQuery (2014)

#125

Post by emptyparadise »

krapp wrote: post #37
abiogenesis wrote: post #36

Now only if someone could combine the snippets on the right hand side in an easy-to-use library. Oh wait...

no no no... what we need to do is break them down so that each line is a separate library composed of a single function with its own independent dependency tree and test suite, then build another library out of that, all written in a language that compiles to javascript, and publish it to a proprietary package manager. If we're really clever we can probably get it up to several megabytes, require three languages and…

Code golf, except it's maximizing potential security issues.

Re: You might not need jQuery (2014)

#126

Post by arp242 »

robertlagrant wrote: post #101
arp242 wrote: post #59

Earlier quoted context omitted.

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.

If you're not seeing jQuery - as with every third party library - as something that now needs a mitigation plan in case it ever vanishes, and a security monitoring process to keep up upgraded, you're doing it wrong.

Why do I need a migration plan? I have jquery.js saved on my disk; that's never going to vanish, and it's not going to stop working if upstream decides to stop supporting it. And if I discover a bug then I can just fix it myself, just like any code saved on my disk.

jQuery rarely has security issues anyway; and the issues that do exist are usually low-impact. It certainly won't have any more than any code I'll write myself.

Re: You might not need jQuery (2014)

#127

Post by capableweb »

lmm wrote: post #48
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.

> Is saving 10-15 lines worth it if you need an 86.1 Kb vendor dependency? Yes, absolutely. That's a total no-brainer. > Hidden complexity you don't control is the most expensive kind I think. There's oodles of hidden complexity you don't control in any modern CPU, but most developers (rightly!) don't care. Complexity you have to fix bugs in is the expensive type, but IME you're far more likely to hit bugs in your cu…

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

> Yes, absolutely. That's a total no-brainer.

That's what we've been thought but it's not a no brainer at all. Context matters, but you disregard it and only focus on the lines of code, just as the author of the comment you respond to is saying people do.

You're building a marketing page that's not gonna be updated after completed and only gonna be valid for X days? Sure, the code doesn't matter.

You're trying to build a fast and slim UI that's gonna be deployed on routers and possibly loaded on low-power devices? You better care about every single line that gets loaded on the device.

I'm not saying dependencies are always wrong. I'm also not saying it's always right. I'm saying why you need the dependency and the quality of the code it includes is important to consider, and knee-jerk reactions of "of course I'd use it" is hurting the profession more than the library reuse saves us currently.

Re: You might not need jQuery (2014)

#129

Post by john-doe »

6510 wrote: post #87
jonny383 wrote: post #7

Earlier quoted context omitted.

And of course in 2021 you could build the site using Vue with GraphQL and a CDN deployment pipeline with auto scaling :)

Build it as a single document in pure html + inline css with 20 mb of text on it and lazy loading images.

THIS

Re: You might not need jQuery (2014)

#130

Post by zhte415 »

jamiesonbecker wrote: post #20
nobleach wrote: post #14

Earlier quoted context omitted.

jQuery, minified and Gzipped is 30.4kb. That's completely unacceptable for my needs. This is why folks complain about bloat.

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.
Post reply on HN