Earlier quoted context omitted.
I think a lot! For example, the new https://www.whitehouse.gov uses jQuery. When you just want to add a small bit of interaction to a mostly-static site, jQuery can help. There's a current trend to complicate things with a JAM stack that really don't need to be complicated. I've seen people propose something like [NodeJS/Ruby/PHP backend] -> GraphQL API -> React Frontend -> static html Where really they could have ju…
There's no need to complicate static sites with jQuery. All it does can be achieved with vanilla.
jQuery 3.6.0
81–90 of 292 posts
Re: jQuery 3.6.0
#82Earlier quoted context omitted.
> This has been rolled into the Javascript document api via document.querySelector, and document.querySelectorAll. Have you actually compared the two methods in a real website? It's like saying why use Ruby when you can use Java. The Javascript document API is super verbose. No thanks.
Conversely, looking at how you do it through jQuery after seeing how it is in Javascript gives me the same reaction. The fact that jQuery is usually assigned to the dollar sign definitely doesn't help, especially for beginners. The amount of questions I've answered that stemmed from a fundamental misunderstanding of how Javascript works, all because they learned jQuery instead of Javascript, is pretty significant.
Re: jQuery 3.6.0
#83Do people still use jQuery? I thought the biggest advantage of this library back in the day was css selector access of DOM nodes (back when we only had getElementById, getElementsByClassName, and getElementsByTagName). This has been rolled into the Javascript document api via document.querySelector, and document.querySelectorAll. Also there are browser compatibility issues that jQuery solved but a lot of these are so…
Oh yes. Everyday. Still love it.
>…Javascript document api via document.querySelector, and document.querySelectorAll
The jQuery API is still (and probably aways will be) far superior to the native DOM (terser, composable, more expressive, etc).
>…smaller footprint libraries like lodash
jQuery is ≈30k gziped and most likely already cached from CDN.
>…has fallen out of favor of more comprehensible state management inside of JS (like React Hooks, Redux...etc.)
Managing state is hard. There shouldn't be much of it in any single view. IMO, React doesn't bring much to the table in this regard while adding a lot of complexity and heft. Vue is a bit better, but still, I'd much rather use jQuery if given the choice.
If you're building something like Spotify/Slack, I can maybe see the need for virtual DOMs, etc. If you're sprinkling interactivity to your webpage, which is arguably what most of the web should be, jQuery is probably as good as it will ever get.
Re: jQuery 3.6.0
#84Earlier quoted context omitted.
I never understood why people say “We’ve solved your jQuery problem” by introducing getElementsByClassName() or even querySelector(). When I come back to my older app, $(“.my-class”) is still much nicer. jQuery gets out of the way, the class gets syntax-highlighted, and .focus() can’t create an NPE.
One could also save document.querySelector to $ as a constant.
Re: jQuery 3.6.0
#85Do people still use jQuery? I thought the biggest advantage of this library back in the day was css selector access of DOM nodes (back when we only had getElementById, getElementsByClassName, and getElementsByTagName). This has been rolled into the Javascript document api via document.querySelector, and document.querySelectorAll. Also there are browser compatibility issues that jQuery solved but a lot of these are so…
In a world without jQuery every site / devshop uses their own little set of conventions and polyfills (analogous to macros) to add useful abstractions.
In isolation, these are neat. En masse though it means that each site has their own meta language (conventions) which have to be memorized before you can contribute to the code base. Languages like Ruby and Lisp suffer from this too: there are so many minute variants across code based that it becomes hard to truly view them as the same language. jQuery, in the context of JavaScript, is a standardisation track for all those little language additions.
Personally, I just use the native APIs. I don’t work with enough people across enough sites to benefit from standardisation. You will probably find a big overlap between proponents of jQuery and professionals — especially contractors — who work with many other people on many different codebases.
Re: jQuery 3.6.0
#86During the pandemic last year:
> We hope you’re staying healthy and safe while so many of us are stuck at home. With a virus ravaging the planet, we realize that jQuery may not be a high priority for you or the sites you manage. When you do have a moment, we recommend that you review this new version and upgrade.
Some fun:
> I’ve never gotten to say this on a jQuery release, but May the 4th be with you! A short time ago in a galaxy exactly like this one, we released jQuery 3.5.0.
Release notes are also very well thought out and their philosophy is to "move slowly and not break things". I admire that. They go to great extent to provide help about how to deal with breaking changes. Ends with a section thanking the contributors.
Super nice people.
Re: jQuery 3.6.0
#87Earlier quoted context omitted.
> This has been rolled into the Javascript document api via document.querySelector, and document.querySelectorAll. Have you actually compared the two methods in a real website? It's like saying why use Ruby when you can use Java. The Javascript document API is super verbose. No thanks.
You don't have to use all of it though, right? You can choose to only only use the applicable parts: eg: ``` $('.container-element') .addClass('active'); // vs document.querySelectorAll('.my-class-selector') .classList.add('active') ``` I use the native APIs all the time, they are not that complicated or overly verbose. Easily memorized with practice IMHO. Also they are all extremely well documented on MDN.
Re: jQuery 3.6.0
#88Earlier quoted context omitted.
I think a lot! For example, the new https://www.whitehouse.gov uses jQuery. When you just want to add a small bit of interaction to a mostly-static site, jQuery can help. There's a current trend to complicate things with a JAM stack that really don't need to be complicated. I've seen people propose something like [NodeJS/Ruby/PHP backend] -> GraphQL API -> React Frontend -> static html Where really they could have ju…
> When you just want to add a small bit of interaction to a mostly-static site Then I'd reach for Alpine. Very lightweight, and I can use the fetch API instead of $.ajax.
You want to be as confident as possible you can bump to a new version on your old site in 4 years if you have to? Use Jquery.
Re: jQuery 3.6.0
#89Do people still use jQuery? I thought the biggest advantage of this library back in the day was css selector access of DOM nodes (back when we only had getElementById, getElementsByClassName, and getElementsByTagName). This has been rolled into the Javascript document api via document.querySelector, and document.querySelectorAll. Also there are browser compatibility issues that jQuery solved but a lot of these are so…
I never understood why people say “We’ve solved your jQuery problem” by introducing getElementsByClassName() or even querySelector(). When I come back to my older app, $(“.my-class”) is still much nicer. jQuery gets out of the way, the class gets syntax-highlighted, and .focus() can’t create an NPE.
So if your selector is wrong, you won’t actually know, because your code will pretend to run along just fine.
I personally consider that a con, not a pro, and one of my (many) reasons not to use jQuery.
Re: jQuery 3.6.0
#90Earlier quoted context omitted.
> This has been rolled into the Javascript document api via document.querySelector, and document.querySelectorAll. Have you actually compared the two methods in a real website? It's like saying why use Ruby when you can use Java. The Javascript document API is super verbose. No thanks.
How so? Who stops you from doing something like `const $ = document.querySelector`?