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

I loved jQuery, and still do (2019)

withblue.ink

Post reply on HN
Print view View original

131–140 of 189 posts

Re: I loved jQuery, and still do (2019)

#131

Post by wil421 »

Aperocky wrote: post #54
acabal wrote: post #45

I still use jQuery even for new projects. Yes, these days it's possible to do everything jQuery does using native JS, but I find the native version to be much more verbose and its naming conventions to be far less clear. For example, natively getting a list of children is `el.children` but natively getting the parent is `el.parentNode`, not `el.parent`. Meanwhile, natively getting a list of classes is `el.classList`,…

I've used jQuery in the past, but switched to native js/ts. I found that while jQuery offers some nice synthetic sugar, it's mostly geared towards web frontend and actual logic continue to have to reside in native. I'd rather just know one thing (but I'm a backend programmer that only does js/ts for fun, so there's that).

Mostly geared toward frontend? It’s been a while since I used JQuery but I thought it is specifically a frontend library.

Re: I loved jQuery, and still do (2019)

#132

Post by goldenkey »

iso1631 wrote: post #130
rchaud wrote: post #61

Every time anything about jQuery is posted, someone will inevitably post the "You might not need jQuery" site. [0] I look at that site and laugh. Is this supposed to be making the case ~against~ jQuery? Maybe the audience for that site are seasoned developers for whom the vanilla JS syntax is easily understood. Everybody else is going to look at those code snippets and think jQ is the way to go. For people that have…

I assume that's a pro-jquery site I write random bits of scripts for internal use, I'm happy enough to drop the min.js in with my index.js, index.css and index.php files, especially if it means I can continue to use getJSON('/my/url', function(data) { }); Rather than var request = new XMLHttpRequest(); request.open('GET', '/my/url', true); request.onload = function() { if (this.status >= 200 && this.status The 90KB o…

You could have used async/await and fetch along with a polyfill if you are concerned about compatibility with older browsers. ;-)

Re: I loved jQuery, and still do (2019)

#133

Post by faitswulff »

gmiller123456 wrote: post #116
acabal wrote: post #45

I still use jQuery even for new projects. Yes, these days it's possible to do everything jQuery does using native JS, but I find the native version to be much more verbose and its naming conventions to be far less clear. For example, natively getting a list of children is `el.children` but natively getting the parent is `el.parentNode`, not `el.parent`. Meanwhile, natively getting a list of classes is `el.classList`,…

> but natively is the mouthful of `document.querySelectorAll('selector')` I'm curious as to whether there's a proper use case for querySelectorAll. I always use the getElementsByClassName, getElementById, and getElementsByTagName based on what I want. I find the more general querySelectorAll to be too likely to produce a bug when someone uses a CSS class name that equals a tag or ID. You can make it work, but I find…

I use it all the time for bookmarklets and userscripts when I want to customize a page that I can't modify directly. Vendor site showing too many out of stock items? querySelectorAll('div.out-of-stock') and wipe them all out. Filter options not good enough? querySelectorAll('div.price').forEach( /* delete products between x and y prices */ ).

Re: I loved jQuery, and still do (2019)

#134

Post by andybak »

FinalBriefing wrote: post #120
rchaud wrote: post #101

Earlier quoted context omitted.

If it's a corporate environment, the standards are different, understandably. But the hostility to jQuery is also primarily concentrated among corporate devs that seemingly cannot imagine that jQuery might be valuable for use cases other than their own. Not every site out there is an database-driven SPA that needs QA review and a deployment pipeline each time an update is made. Lots of sites are just simple WordPress…

> little bit of a facelift Proceeds to download 30kb (compressed) swiss army knife of a library when just a toothpick would do. jQuery is about as much of a gateway to ES6 as pot is to heroin. Devs who still use jQuery have had 10+ years to learn `document/element.querySelectorAll()`. Longer for event listeners.

Gosh. 30kb.

> Devs who still use jQuery have had 10+ years to learn

Or possibly we learned it in 9 years 11 months ago and still think jQuery was a more elegant solution.

Re: I loved jQuery, and still do (2019)

#135

Post by goldenkey »

recursive wrote: post #107
gunapologist99 wrote: post #97

Earlier quoted context omitted.

True, but jQuery does a lot more than just id selection with $! You could just extend the function to detect '.' vs '#', and do a class selection as well. And then add all of the selectors, subselectors, etc. (similar to, but far more powerful than css3's selectors.) and if you go far enough, you reinvented zepto (but still a long way from jQuery) (actually, since $ is basically synonymous with jQuery, it'd probably…

> True, but jQuery does a lot more than just id selection with $! Yes. For a high degree of jquery-compatibility, you can use my library. const $ = document.querySelectorAll.bind(document);

This comment made me spit my drink out. People forget about bind, it's nice to replace the old closure patterns.

Re: I loved jQuery, and still do (2019)

#136

Post by bstar77 »

mjgoeke wrote: post #128
throwaway_egbs wrote: post #108

Earlier quoted context omitted.

Right, I get that. What I don't get is why Node is a requirement for a JS compiler. Is that just to get the runtime? I'd always thought of Node as a server on top of a V8 runtime. (Thank you for your patience with this backend dev who finds your whole world very confusing.)

I had a similar jarring experience moving from C# dev to web apps. I knew I wanted to use building blocks available via npm. I went to download npm, and found the way you get npm is via installing node.js Node js and the the package manager are inextricably tied together. Node js provides a local js runtime environment for the e.g. dev time packages to execute. It's also the api for interacting with the filesystem. S…

NPM was born out Bundler for Ruby. Node doesn't require you to use npm, but they are bundled together now. There are other popular registries like Yarn.

Re: I loved jQuery, and still do (2019)

#137

Post by andybak »

cptrp2101 wrote: post #34

I had a big post but deleted it all. I can more concisely say this: The people here saying they still use it have so far demonstrated what I always say. If you're using jQuery, it's time to go back and relearn javascript. Most people should REALLY research the querySelector and querySelectorAll DOM methods. I've always felt that jQuery encourages you to let your skills stagnate and you don't learn what your code is a…

> If you're using jQuery, it's time to go back and relearn javascript.

I've roughly as fluent in vanilla as I was in jQuery and I still think jQuery was a nicer, more elegant, more humane API to the DOM.

Re: I loved jQuery, and still do (2019)

#138

Post by sir_pepe »

gmiller123456 wrote: post #116
acabal wrote: post #45

I still use jQuery even for new projects. Yes, these days it's possible to do everything jQuery does using native JS, but I find the native version to be much more verbose and its naming conventions to be far less clear. For example, natively getting a list of children is `el.children` but natively getting the parent is `el.parentNode`, not `el.parent`. Meanwhile, natively getting a list of classes is `el.classList`,…

> but natively is the mouthful of `document.querySelectorAll('selector')` I'm curious as to whether there's a proper use case for querySelectorAll. I always use the getElementsByClassName, getElementById, and getElementsByTagName based on what I want. I find the more general querySelectorAll to be too likely to produce a bug when someone uses a CSS class name that equals a tag or ID. You can make it work, but I find…

getElementsByClassName and getElementsByTagName return live HTMLCollection objects that update when the DOM changes (or rather get re-computed when you access their contents following a DOM change). Depending on what you do with them, you may end up with worse performance compared to the NodeLists returned by querySelectorAll.

Re: I loved jQuery, and still do (2019)

#139

Post by gunapologist99 »

bstar77 wrote: post #98
gunapologist99 wrote: post #96

Earlier quoted context omitted.

You are literally criticizing jQuery for its best features. Not having outdated libraries and potentially dangerous vulnerabilities is a huge plus for jQuery. Do you think just because you use a build tool for modules from all over the npm-verse that vulnerabilities just magically go away?

jQuery has had its share of dangerous vulnerabilities. https://snyk.io/vuln/npm:jquery

agreed, but it's only one library, and might be the only one you need; really, it has an excellent track record considering that it's been around longer than npm itself.

Re: I loved jQuery, and still do (2019)

#140

Post by jwommack »

gmiller123456 wrote: post #116
acabal wrote: post #45

I still use jQuery even for new projects. Yes, these days it's possible to do everything jQuery does using native JS, but I find the native version to be much more verbose and its naming conventions to be far less clear. For example, natively getting a list of children is `el.children` but natively getting the parent is `el.parentNode`, not `el.parent`. Meanwhile, natively getting a list of classes is `el.classList`,…

> but natively is the mouthful of `document.querySelectorAll('selector')` I'm curious as to whether there's a proper use case for querySelectorAll. I always use the getElementsByClassName, getElementById, and getElementsByTagName based on what I want. I find the more general querySelectorAll to be too likely to produce a bug when someone uses a CSS class name that equals a tag or ID. You can make it work, but I find…

It’s slower but, assuming you have control over page content, I’d think the answer is probably pseudo selectors or sibling selectors. The more complex stuff really.

Of course if that’s a need the page needs work but, not everything is “fixable” in time limited business cases.

Post reply on HN