Live data from Hacker News

You might not need jQuery (2014)

youmightnotneedjquery.com

201–210 of 241 posts

Re: You might not need jQuery (2014)

#201
post #173

I bought into this a few years ago and ended up regretting it. My code has become much harder to maintain and read due to all the extra boilerplate code, and it probably has hidden bugs and compatibility issues that I'm not even aware of. And for some things I still ended up requiring jQuery, because they just weren't feasible to do in vanilla JS. I have actually gone back to making heavier use of jQuery again these…

I guess the irony is that jQuery is indeed written in JavaScript, so whatever you set out to do is still "feasible to do in vanilla JS." With that said the main difference is of course that there's far more people involved in maintaining jQuery than there is on most people's individual codebases. Personally I try to make do without it, if nothing else than because it forces me to learn JavaScript better.

Of course - what I was trying to say there was that it was not feasible without writing hundreds of lines of extra code, with all the development and maintenance cost that brings. In some use cases that trade-off may make sense, but in mine it doesn't.

Re: You might not need jQuery (2014)

#202

Earlier quoted context omitted.

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

I'm not sure. It was kind of traumatic, but on the other hand it's a very old site, so it was obvious that there might be some dead bodies in the basement. Found one, ignored the others.

Re: You might not need jQuery (2014)

#203

Earlier quoted context omitted.

Well sure, you could do so much better with a small library like Vert.x (which I love). But getting an entire app framework with config/routing/db connectivity/etc is just so easy with Spring Boot. Plus, you get a vast ecosystem. Now the memory usage and compile times? Yeah, youmightnotneedspringsmemoryoverhead.

If someone can buy this argument but not then immediately understand why a library like jQuery or React is popular, that’s a shame. It’s the exact same reasons: maturity, flexibility, and community/precedent.

It's basically a hard no from me on adding a dependency that buys me next to nothing, and bloats my payload to a customers/users mobile device. In that industry, every byte counts. In backend Java/Kotlin apps? I can pay the extra money for memory usage. I cannot ask my users to do the same.

Re: You might not need jQuery (2014)

#204
It's funny this site doesn't mention dialog - the only feature I'm using that is hard to replace by vanilla JS...

jQuery speeds up development, but in most situations it's straightforward to replace.

On the other hand, I never remove React (and especially Reagent) from an existing site - too much effort, too much to break.

Re: You might not need jQuery (2014)

#205

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.

I'm absolutely NOT being sarcastic. In my time at Overstock, I prided myself on a mobile-first bundle that was 200k... for the ENTIRE app. The time to first meaningful paint and time to interactivity were fantastic. This was especially true for 3G and emerging markets. There is NO WAY, I'd add 30k so I could select/iterate DOM elements. I simply see that library (as well as a few other common ones) as part of the problem we see in JS development.

Re: You might not need jQuery (2014)

#206

Earlier quoted context omitted.

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.

Like I mentioned in another response, my bundle was 200k. 30k would have been significant bloat.

Re: You might not need jQuery (2014)

#207

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.

Agree with this. Fancy libraries like React/Vue etc are great, but they require more human resources in terms of development and add more complexity to your development cycles. I am working on a side project and initially got tempted to use Vue for the front-end but once I stepped back and re-thought about it, jQuery was a no-brainer in terms of how much I can achieve in the time I have.

Why do jQuery at all now? IE 11 is no longer supported. All major browsers are evergreen and, except for some small edge cases that jQuery didn't really support anyways, they are pretty much completely unified in the APIs they support. If you are really worried about that 1% difference, then you can use tools like babel to cover those cases.

The only reason to reach for jQuery, IMO, is familiarity. If you don't want a framework, then just write vanilla js.

Re: You might not need jQuery (2014)

#208

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.

agree, i think this page has a lot of value in explaining how jquery works which is very valuable for beginners, need a more accurate title i guess

Re: You might not need jQuery (2014)

#209

Earlier quoted context omitted.

If someone can buy this argument but not then immediately understand why a library like jQuery or React is popular, that’s a shame. It’s the exact same reasons: maturity, flexibility, and community/precedent.

It's basically a hard no from me on adding a dependency that buys me next to nothing, and bloats my payload to a customers/users mobile device. In that industry, every byte counts. In backend Java/Kotlin apps? I can pay the extra money for memory usage. I cannot ask my users to do the same.

Bundlers these days are very good. Any code that isn’t used is removed with tree shaking/dead code elimination, and React can be swapped with Preact which has a lot smaller bundle size as well.

Re: You might not need jQuery (2014)

#210

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.

It's a serious hurdle when pReact is only 10kb unzipped (13kb with hooks) while jQuery is 89kb.

Accounting for 70% average minification and 40 characters per line on average, that's around 6,500 lines of normal code shipped "for free" by using pReact instead where there's both no wire cost and no extra parse time.

Post reply on HN