by notoriousarun on 6/29/21, 2:45 PM with 182 comments
by acabal on 6/29/21, 3:43 PM
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 when I'm getting children I also get a list, so why not `el.childList` instead of `el.children`? Natively cloning a node is `el.cloneNode(true)`, so now I have to remember what `true` is for and whether I want it or not (surprise: the default changed between JS versions, so the "optional" argument must always be included for compatibility!). Probably the most commonly used line in web JS in jQuery is the terse `$('selector')` but natively is the mouthful of `document.querySelectorAll('selector')`.
So while jQuery isn't strictly necessary, it's certainly a nice syntactic sugar, and IMHO a more sane and consistently-designed API than native. It's a great choice for developers who want avoid big frameworks like Vue and get as close to plain HTML/JS as possible, but still want a pleasant JS development experience.
by rchaud on 6/29/21, 3:58 PM
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 struggled through HTML and CSS, there is perhaps nothing more deflating than to realize that even basic UI interactivity requires JS. But with jQuery the code snippets needed are short and understandable. Vanilla JS in comparison looks like an entirely different language.
by legitster on 6/29/21, 3:23 PM
I can just drop in the library onto any existing webpage, and have almost complete control of the DOM with just a few lines of code. And the built in actions and animations are all so simple and perfect for the web. And the structure and naming is so good that I rarely need to look up any references anymore.
I get that browser support isn't as important as it used to be, but it is nice to know that you can just use an effect in jQuery and it will just work exactly as you expect it.
by mortenjorck on 6/29/21, 3:50 PM
I know React enforces some better practices that my spaghetti-jQuery of yore never followed, and that I was getting a crash course in those practices at the same time, but I was nonetheless surprised at just how slow I felt working in it! It gave me a new appreciation of just how accessible jQuery is, and how intuitive its concepts are to someone without a background in software development, perhaps for better or worse.
Obviously this is a bit of an apples-to-oranges comparison, given the intended uses of the two frameworks, but for simple projects, it's hard to imagine a better balance of accessibility and flexibility than jQuery.
by VWWHFSfQ on 6/29/21, 3:23 PM
by cptrp2101 on 6/29/21, 3:33 PM
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 actually doing. Learn what the current spec has to offer. You don't need another dep just to target dom nodes ffs.
by franze on 6/29/21, 3:14 PM
I really learned to appreciate jquerys clean codebase at that time. Learned a lot about the DOM and how to misuse it.
by mkl95 on 6/29/21, 3:07 PM
by vlunkr on 6/29/21, 3:54 PM
Yeah, we've all seen spaghetti code monstrosities that involve lots of jQuery, but it's just a library, it can't be blamed for people not knowing how to structure their code.
by tossaway9000 on 6/29/21, 8:11 PM
by BlameKaneda on 6/29/21, 3:00 PM
by developeron29 on 6/29/21, 3:27 PM
Best being
$("#id") replacing document.getElementById("id");
Makes code look cleaner
by neals on 6/29/21, 4:48 PM
by thoughtpalette on 6/29/21, 3:01 PM
by bstar77 on 6/29/21, 4:01 PM
The problem is jQuery has no business being used today unless you have to maintain legacy code. Even then I would deprecate jQuery wherever possible. Using jQuery for a "quick and dirty" application today is just terrible and it sends the message to green devs that jQuery code slinging is a skill worth having.
If you like quick and dirty, just make sure you have a working Node.js environment and generate a simple project that supports Webpack or Parcel. You will get all the advantages of Babel and Polyfills (if you need them) with little to no effort.
jQuery has no value except for maintaining legacy code. jQuery was useful back in the day (and John Resig had the best solution), but I don't love it anymore. In fact, I have serious judgements of the devs that use it that should know better.
Edit: I should note that jQuery is bad because it has no state management and you cannot easily track side-effects. I would much rather see someone use something like Svelte and construct the functionality with modern best practices while keeping a very small footprint.
by thera2 on 6/29/21, 3:46 PM
Addititionally, jQuery loads on the first request and sits in local cache thereafter. And it could already be in local cache if you use a CDN.
by warpech on 6/29/21, 3:54 PM
There is probably no reason today to use Prototype.js, however, jQuery still is a better choice than React/Angular/Vue for small projects if the author prefers some syntactic sugar over plain DOM.
by ChrisArchitect on 6/29/21, 3:14 PM
by ricardo81 on 6/29/21, 3:33 PM
If I had a choice, I'd go with one of the reactive libraries, I've used Vue. For me, if you're relying on Javascript IMO it gets the job done quicker.
It'd be interesting to see what jquery is used for in aggregation of all its usage. For me it was always selecting element(s) and XHR requests. With fetch (and a polyfill for IE), and the likes of querySelector it seems that a lot of the problems jquery solved have also been solved by the majority of popular browsers.
I say that as a layman of client side dev, happy to be corrected.
by drummer on 6/29/21, 3:18 PM
by mouzogu on 6/30/21, 9:18 AM
I find jQuery and Bootstrap great for fast prototyping. The thing I love about jQuery is the cross-browser compatibility. I know things have improved but I have very little faith in native JS "just working" as I would expect on all browsers.
But of course it was not designed for building reactive apps and so should not be used for that. It's nice just for fast-and-dirty UI interactions and animations.
by locallost on 6/29/21, 9:18 PM
by whalesalad on 6/29/21, 3:17 PM
by cmer on 6/29/21, 3:30 PM
Now that these browsers are no longer relevant and support has been removed from jQuery, what is the performance hit, if any for using jQuery as opposed to vanilla JS?
I agree with many, I find the jQuery syntax to often be better than the alternative.
by nailer on 6/29/21, 5:51 PM
'Rich Internet Applications' were not the same thing as web 2.0 sites. Rather, they were a precursor to modern concepts like Electron and webview2.
by mbostleman on 6/29/21, 5:55 PM
OWA and Ajax appeared 6 years earlier. Why would Gmail be considered the milestone instead?
by racl101 on 6/29/21, 3:42 PM
It was a great library for what it did and it holds up a lot of sites still.
by princevegeta89 on 6/30/21, 12:24 AM
Oh and BTW it pairs really well with StimulusJS. I've used it thoroughly and it's been a godsend
by byteface on 6/29/21, 6:58 PM
by shmiga on 6/29/21, 8:24 PM
by evo_9 on 6/29/21, 8:18 PM
by olliej on 6/30/21, 7:02 PM
by thrower123 on 6/29/21, 9:17 PM