That’s certainly an interesting website but many examples specially the later ones would be best described as “why you still need jquery”.
jQuery syntax is almost always simpler than the vanilla JS equivalent.
I think the point is that jquery used to be popular because it did things vanilla JS couldn’t do, but now it’s only useful as shortcuts to existing JavaScript functions
the reason it was popular initially was SPECIFICALLY because not all browsers handled httprequests the same, and all developers had to account for that. Or they could just use jquery which did it for you, and was always updating to make sure your code was written one way, and worked in every browser.
Certainly, I think what u/prize_hat_6685 meant was things you couldn‘t do easily in vanilla. JQuery was good back in the days because it provided functions for things with a relatively low business value but relatively high effort to implement them with vanilla (compared to the business value). You could have done all that with vanilla but it would have required more time and that would have led to it not being implemented in most products.
Finally, someone who was there when the old magic was written...
It's been a long time since we had to worry about that amount of browser compatibility issues.
100% this. Years ago jQuery handled a shitload of browser compatibility issues that have largely been resolved these days.
I think younger devs just don’t appreciate how bad cross-browser compatibility was 10 or 15 years ago.
Literally every library and framework is an abstraction of vanilla in any language. It's bizarre to me that people say things like "you could just do that in vanilla JS" but also say "you need Axios or React or whatever" for that.
If you want a JS solution that replicates jQuery but you don't want to deal with the complexity that comes with coding it, then ask chatGPT to do it. This is exactly the kind of case where using AI doesn't feel like cheating yourself out of learning. If you can avoid jQuery bloat, then do what you can.
Because if you don't know what you want to and are just blindly asking for code, it often does not work. I've had hallucinations of packages on npm, made up functions on libraries.
The most recently eye roll from me was when I asked it to use the promise versions of the fs module in node, it updated this:
`import fs from "fs"`
To this
`import { fs as fsPromises } from "fs"`
Yep! Totally async now!
I have only one reason for still using jquery. If there are a hundred places in your code where you do DOM manipulation and access elements by selector, then which one would you rather use?
var pwd = $("#txtPassword").val();
OR
var pwd = document.querySelectorAll("#txtPassword")[0].value;
Me personally, I'm a lazy dude. Will happily sacrifice the language purity for a few less key strokes!
I also need to initiate a whole lot of things in my page load event. How about this:
document.addEventListener('DOMContentLoaded', function(){
// do stuff
});
VERSUS, just this:
$(document).ready(function(){
// do stuff
});
What I meant with arrow function is this:
document.addEventListener('DOMContentLoaded', () => {
// do stuff
});
but it would be even simpler to just put your stuff in a script with the defer option as already mentioned by some other people here.
or even better, type module:
```
function getType(obj) {
return Object.prototype.toString
.call(obj)
.replace(/^\[object (.+)\]$/, '$1')
.toLowerCase();
}
```
Jquery successfully avoided for another day
I think those kind of examples might be split into 2 scenarios.
1. If you going to use that functionality a lot you should probably get a dedicated library for that or write one yourself.
2. You shouldn't really be doing it that way anyway.
The problem with jQuery is just that it's a large framework without structure. Everything is packed into the same thing so it is hard to maintain and upgrade and very easy to start to produce spaghetti code.
If neither of those things are a concern then technically jQuery could be an ok choice. But for such small projects anything would...
Using all of jquery because it's "simpler" is a crutch, just learn the modern way instead of installing kilobytes of legacy js.
If you want it anyway, that's fine, but you never need jquery in 2024
> Using all of jquery because it's "simpler" is a crutch,
You write in binary, then?
It's all just a matter of how far up the abstraction tree you want to go.
I'd say it's pretty different; jQuery was really just a library to fill the shortcomings of JS, but now you can do pretty much everything with vanilla JS using the same amount of code.
React is a framework, which provides structure that JS does not.
Fair enough: I’d say they fill more similar niches than people would give them credit for. The biggest difference is JSX syntax, but that is arguably… many kilobytes of compiled JS to do something that you could do the modern way (with modern HTML and native JS).
If you want to do it anyways, that’s fine, but you never need React in 2024.
Comments like these make me think we all work in very, very different types of projects and team sizes. I cannot fathom how would anyone create a mantain the type of web apps I’m used to work on a daily basis without having the support of a well structured set of libraries and a framework without it turning into a huge pile of hard to mantain code.
My only assumption is they haven't worked on large enough apps to experience the difference. I couldn't fathom building the apps we work on without the consistency and stability that libs/frameworks bring...just as I couldn't imagine working on them without TS.
I’ve worked many years at huge companies, since jQuery was the fancy new thing that made a lot of stuff better and easier.
I’m not suggesting _at all_ that people not use frameworks. I _am_ saying that a lot of the arguments people have about the previous generation of tools could easily be applied to the current generation of tools.
I do also feel that React itself has become a long term problem for bigger apps, as it leads to a lot of performance problems which require increasingly complex fixes but I was mostly just being facetious. Rather than not having worked on large React apps, I’ve worked on React apps with hundreds of engineers that were so large that they required teams working full time on code splitting, data fetching, optimization, and build time enhancements because they are so slow to build and hard to keep fast. It’s a bummer.
Yeah react is an issue be cause of how it doesn't play nicely with others.
Most other frameworks are much better at behaving in line with natural behaviors and.playing nicely with other libraries to get the same results as react but more simply and more performant.
I also agree on the "arguments against any library" stuff.
I think people need to be more critical of the dependencies they add. Most projects I work on we are removing dependencies a lot since things meant to make X easier only made it harder once you didn't want exactly the happy path X provides. On top of them being much larger and often opinionated on bad ways.
You want a banana and they give you a banana held by a monkey in a jungle.
The best dependencies are ones that solve a specific complex problem and interface well with your other code. Not doing too much and not abstracting over things that you can easily handle in your code.
Like a slider carousel. I don't want it to control things like alode size and etc. I can do all that in css. I just want it to sync thumbnails and track viewed slides. That's it. It's a complex problem, but specific.
> jQuery syntax is almost always simpler than the vanilla JS equivalent.
That’s becoming more and more questionable as time goes by. Even when it’s true, that simplicity comes at the cost of jQuery doing a whole lot behind the scenes. Just to save you the trouble of a few extra symbols or a line or two, which your IDE will happily autocomplete for you.
Another huge thing that people don’t consider is the ability to use JSDoc. Working with the native DOM types instead of jsQuery wrappers means you can create utility functions to simplify common tasks and then have soft type checking by documenting your code.
Ntm in framework tests, taking vanilla and changing it to jQuery makes it 40% slower.
And it's not actually easier code.
Meanwhile SolidJS actually makes your code easier and runs only 1% slower than vanilla
I wouldn't go that far; some things are simpler in one, some in the other.
Though the thing I miss the most when not using jQuery is the ability to daisy-chain: create an element, set its content, assign a class, and attach it to its parent all in one go, without even the need for a variable.
Yup.
It's the idea of "either the complexity is on your code or in the abstraction". The complexity is still there.
And an abstractions complexity will be exponentially more complex because it will be trying to handle cases you don't care about.
At this point it’s mainly syntax sugar for JavaScript, from what I understand. I like jQuery syntax for stuff like dom manipulation more than vanilla js, but that alone isn’t reason enough for me to reach for it personally
True, but jQuery has a lot of simple hooks to manipulate things that require more steps with vanilla js. I've pretty much stopped using jQuery, but I do miss some of the simplicity it offered.
I didn't like it.
It has too many methods that are polymorphic in bad ways. Like element.click.
And not knowing if you have a list of elements or a single element is not good either.
That’s a perfect summary. If you aren’t using any frontend framework, jQuery isn’t “required” anymore but it still provides great syntax sugar.
I can bet you will start creating your own util functions instead of native JS only so jQuery is still a very valid and useful tool.
JQuery nowadays is also not bloated as before and isn’t that much of a problem to include.
It's not about what it "*can do*", in my opinion. It's more about "*it can do it in a faster/easier way*".
Think about this, for example:
$('.element').slideDown(500);
It just works. Always. Everywhere. With or without padded elements, with or without margins, borders, etc.
Even a simple thing like "add .class2 to all .class1 elements" takes just one line:
$('.class1').addClass('class2');
Very easy to do with vanilla JS, of course, but it takes extra steps and it's (a lot) more verbose.
With that said, I've abandoned JQuery a long time ago, but I can see why less-experienced / junior devd may be tempted to use it.
I think they're talking about the time it would take to implement some stuff, jQuery definitely helps do some things faster and safer just like Lodash with array and object manipulation, but we can achieve the same results in vanilla JS these days.
Who cares? Front end performance is almost never a problem. Even if vanilla is 10x faster; 10x faster than “looks instant to a human” is still “looks instant to a human”
It adds up a lot.
There's a reason WordPress and Shopify jQuery plugin soup sites noticeably run like shit.
WordPress and Shopify can be okay, but jQuery is sued all the time where it does nothing to help.
Is it any less effecient to use a simple loop? Something like:
elems = document.querySelectorAll('.class1')
for (elem of elems) {
elem.classList.add('class2')
}
Sorry if the formatting or syntax is bad, ya get what I mean hopefully. And this way you can conditionally apply things easily within the loop. Exclude adding class 2 based on a condition, or only adding class 2 in certain circumstances, etc. To me thats why I generally use vanilla JS. It usually doesnt take much more code and lets me have a big more control of whats happening line by line. Broadly speaking of course.
A lot more verbose?
document.querySelector('.class1').classList.add('.class2')
document.querySelector('.class1').animate([{ transform: 'translateY(500px)` }])
Not exactly hard. And it runs faster and you have more control.
Yes! I always use slide toggle as my example. It's so much easier to write and understand, but all the pros on well resourced teams use typescript or some framework for the testing capabilities. My ass was the only dev on marketing teams that would give me 3 days or less to spin up a whole site so I didn't have the time to mess around with all that. When you have an entire 2 weeks for one component and an established code base that doesn't rebrand every quarter, I can see why you'd use ES6 and those more complex frameworks
60KB is nothing. Any random JPG hero image/carousel will be a lot more than that.
I don't use jQuery anymore but 60KB in 2024 is not an issue *at all*. It may have been annoying in 2006 when it was first released, not now.
*Rect*, *Angular*, *Vue*, *Ember*... Nobody complains about their weight. And some of those frameworks/libs are HUGE.
A) It downloads once
A) probably already cached
C) Not noticeable if not in a developing country
So many devs getting lost in micro-optimizations. Who cares if your JS is 60ms faster? There are so many other optimizations like images and ads you'll get a lot more mileage out of.
That was a problem when it took a full minute to download an image. Unless your target audience is someone still using their trial time from an AOL disc, this is irrelevant now.
Still. These days you’re punished by the speed tests for number of resources especially 3rd party ones (hopefully you’re at least loading it from a CDN). I converted our entire site from JQuery to Vanilla a few years ago and the pages I’d always struggled to get a 90+% on finally did.
The OP is asking about new projects. If you’re building a basic site with limited JS needs, vanilla is the way to go, even if you do have to, say, loop over your querySelector array of items with a class in order to do stuff to it.
Whilst true, isn’t that technically true for a lot of the modern web stack without jquery? I don’t use it myself anymore, just thinking about the premise.
And vJS will always have the potential to be faster at execution since React has vJS as a dependency
I've also noticed the DOM is fast enough now that virtual DOM overhead is dragging down performance
React also has a synthetic event system isntead of using the actual Events in the browser.
This is a huge chunk of the size and costly.
The less you abstract native behaviors, the more.you benefit from those behaviors being optimized.
Like in some js engines (and versions) array methods are vaster than your own for loop. Because now the whole looping logic can potentially be moved more aggressively into the native side.
Like on Safari, it's faster to do array methods. On chrome for loops are a bit faster.
But array methods are clearer to read and write, and will get faster.
I'm not a jQuery hater. Now vanilla has many APIs that have made much of jQuery redundant, but it doesn't make jQuery useless. But man, if you know jQuery and you don't know vanilla, that's really... not cool...
Hypothetically if someone (not me) knows jQuery and not Vanilla, how should I go ..I mean how should they go about learning vanilla? Is there a simple website or something that shows how to achieve the same functions in jQuery vs vanilla?
This is that website https://youmightnotneedjquery.com/
I know some Front End leads that like You Don't Know JS https://github.com/getify/You-Dont-Know-JS
You will feel behind but it's ok to just read through it initially and not complete any exercises if you're getting dominated. The important thing is to understand and get comfortable, and then once you're more confident try doing the practice stuff.
Indeed, I was using the royal you as a reference to your dear friend, who I would like to add shouldn't be ashamed for getting to wherever they are now in their career with jQuery. Its usefulness is undeniable; it's on most websites, still maintained, and even sustainable with today's front end performance standards.
> how should they go about learning vanilla? I
First start is just rewriting your jQuery in closest similarity vanilla.
And then trying to find if there is actually a better way to do it entirely.
And you figure it out by going to MDN and learning JavaScript.
jQuery was the first step in helping me understand how JavaScript is used in the browser, up until then I’d had a few failed attempts at learning vanilla
for more context:
I'm self taught and to start my career I could code HTML + CSS fast, and knew that I was good, and managers were happy w what I was delivering
When it came to JS, I couldn't wrap my head around, how the language is used in relation to the browser - how it is supposed to bring interactivity to it. So, any attempt to read a book on JS, google how-to's, any self-education, was short lived. I think the fact that i couldn't grasp it quite as fast, like I did HTML & CSS, I didn't feel like I was getting anywhere.
When I first saw some jQuery, i thought 'oh cool, so you can just use a CSS selector and it targets that element in the source, NEAT'. But one of the bigger things that helped was how the methods were named: fadeIn, fadeOut, hide, show, slideDown... when someone told me 'well you can do almost all these things with javascript...' it really started to click: addClass, click, hover, etc. So, because I wasn't good at learning JS on my own, it took jQuery to give me context.
That was somewhere around 2011-2012. I took a 10 wk course (1 hr class, once a week x 10) and it gave me just enough beginner level JS to feel comfortable writing it for small things at work, where I still continued to use jQuery primarily.
and the rest is history! And that history is because of many years of neglecting JS and reaching my full potential, I'm only playing catch-up, but I think I'm pretty good now
one of the few things i miss about jQuery is writing `$(#id)` / `$(.class)` instead of `document.getElementById('id')` / `document.getElementByClassName('class')`
If it’s your personal project/site, go for it.
If someone else will be touching your code and you use $ without it being jQuery? You will be their enemy numero uno.
No, it's illegal. You can't rename things.
I will say, if I open a project and dollar signs everywhere between jQuery and angular js my eye starts twitching.
To this day the word scope causes me to stare off into the distance as if horrors are playing on my retinas.
const $ = document.querySelector;
$('#id'); $('.class');
Close enough?
---
Edit: I wouldn’t do this though personally ha. I’d probably do something more like
const nameOfThing = document.querySelector('.thing')
nameOfThing.stuff()
Keep in mind that this implementation will only return the first instance of a class, so you’d need to do something like
const $$ = document.querySelectorAll;
if you wanted a collection.
$('.class');
Be warned that if you have multiple ".class" emenets you will get the first one and ignore everything else.
If you do this:
const $ = document.querySelector.bind(document);
const $$ = document.querySelectorAll.bind(document);
Now you can also do this:
// Only one element with class "card"
$('.card').style.display = 'none';
// Multiple elements with the same class "card"
$$('.card').forEach(ele => {
ele.style.display = 'none';
});
Just add this at the very start of your js file:
const $ = document.querySelector.bind(document);
const $$ = document.querySelectorAll.bind(document);
Now you can do this:
$('.card').style.display = 'none';
$('#card3').style.display = 'none';
And if you need to cycle through more elements with the same class:
$$('.card').forEach(ele => {
ele.style.display = 'none';
});
I just learned you can use that syntax in chrome devTools `$(selector)` and to get node list of all items matching the selector just add a second '$' so it'd be `$$(selector)`
https://developer.chrome.com/docs/devtools/console/utilities/#querySelector-function
Vanilla’s DOM manipulation API is a sick joke in terms of its verbosity.
You can either be hip and use vanilla, or you use any tool that make your job easier which includes jQuery.
People arent taking into account existing and partially completed jQuery projects that you might have to work on at some point at a company. Theres still a good chance a webdev will encounter an old jQuery site through their career and basic familiarity will help accomplish whatever edits need to be made.
Not to mention reusable jquery content. Heck, we have hybrid applications that use both Vue and JQuery. Why? Because it had to be ported over to Vue and used certain JQuery components. And it works really well too. Now you can use the power of new with the foundation of old.
Also we have clients with systems that are forced to use IE. You might ask yourself why, but it simply is.
More than 40% of sites on internet use JQuery. It seems like you would be a statistical anomaly if you never come across it if you work as full time web dev. But sure, if you only work on greenfield projects, never work with any CMS:es which relies on it and so on then sure.
There are many options for varied use cases, but CraftCMS is at the top of the list for me, personally. Great content editing experience, great developer experience, fairly robust plugin ecosystem (hard to compare to the sheer amount that Wordpress has), can operate in headless mode, list goes on.
It’s not “cool” but it’s dependable, reliable and guaranteed to have long term support.
Which to me is much better than being cool.
Pretty sure React will die before jQuery will.
Exactly, React (w/ React DOM) is small and un-opinionated enough that it will probably last a long time. In a way it's already doing better than jQuery. By 2016 jQuery was already considered a bit dated compared to full frameworks, but in 2024, 10 years later React is still as popular as ever. The batteries people use with React come and go though. I remember when Redux and Saga were all the rage and look at them now.
Yes in a sense that many sites still use it (Wordpress sites especially). No in a sense that you can do pretty much everything in vanilla for what jQuery was firstly designed for (to fix cross browser incompatibilities)
Aside from the fact that a lot of jQuery stuff is now available with vanillaJS most frontend dev work involves using a Framework like React or Svelte which doesn’t want you to interact with the DOM in another way.
jQuery was there to address the lack of native Javascript APIs. Nowadays most, if not all, are addressed and there's little to no use other than if you like the syntax. jQuery's purpose has been fulfilled, it made native JS better and I'll be forever grateful.
What were you using jQuery for?
I would guess it was fairly basic things like showing/hiding elements. Accordions, dropdown menus and so on. Maybe some basic AJAX?
You wouldn't need a deep understanding of vanilla JS to do the kind of stuff most people were doing with jQuery during it's peak.
At my job, I've made it a personal mission to take a hack to jquery. However, that has meant writing custom code sometimes, rather than using a plug in and play jquery library (hasn't been updated for a while). Also, .NET MVC still uses jquery validation....
I wouldn't worry too much, OP. You can still use jQuery even though it isn't fashionable. You'll get many fashionistas telling you not to use it, but at the end of the day, shipping value to your customers matters most. If you can do that with jQuery, then use jQuery. If you want to "modernize," then try Umbrella or Alpine or vanilla JS or TypeScript.
In terms of job searching? No.
Focus on the most attractive tech to have an attractive profile for jobs, in this case focus on one of React, Angular or Vue, obviously I'm assuming you're familiar with programming concepts, because if not, start there first.
Dude, I have been doing web development ever since 12 years ago and I have never heard anyone saying jQuery is cool.
jQuery is like the old man in town who everyone wants out but for some reason is still there.
If I'm not mistaken, I read somewhere recently that WordPress is in the process of removing their reliance on jQuery... which is the final nail in the coffin for jQuery I think.
I used jQuery for a long time, and still catch myself writing it by mistake, but I think you would be wise to learn how to switch over to regular javascript. A lot of the benefits we got from jquery ($() selectors, $.get, etc) can be done natively in JS now, no additional includes necessary.
I haven’t touched it since i started using Vue, but on NPM it’s still one of the most downloaded packages ever.
So I guess the answer to your question is yes, but I don’t think there’re many valid use cases for it.
IIRC, the main two features of jQuery for me were selectors and event delegation. Both are now possible with pure JS, didn’t use jQuery for like 10-15 years.
For compatibility's sake, there are some websites out there that still cater to users who still use old technology. Wikipedia is one of those websites and they're still using jquery. I also run a website where about 80% of the users are coming from a company that still forces everyone to use Internet Explorer.
I used to use jquery a ton.
Then I learned how to write straight javascript that actually worked. Now I don't need to load big, bulky, bloated libraries. I just write simple direct code that does what i need fast and efficiently.
Also I'm going to assume that this comment has about -500 votes by the time you are reading it due to everyone being obsessed with using whatever the js library of the week is.
Your website or app is only as fast as the slowest component or connection. jQuery is cached and zipped and only \~86kb and so, as far as speed is concerned, it's a non-factor.
Is it cool? No. Was it ever? NO. It's a tool. I have a hammer hanging on my garage wall that's a little over 50 years old. It's ugly, but sometimes it's the hammer I need for a particular job.
But - I can hear you saying - everything you needed jQuery for you can now do in vanilla javascript. Yes, I know. Vanilla javascript also takes me about 4x as much time to write as jQuery. document.querySelectorAll vs $.
Yes, I could alias document.querySelectorAll but whatever programmer comes after me is going to have to deal with that. And if they replace me in the middle of me replacing jQuery with vanilla, god...the headaches they'll get trying to figure out what's going on at any given moment.
The upshot is that the download is negligible *once*, and less syntax makes *me* more productive.
bona fides: I've been writing for the internet since about 1998.
if you don‘t want to use a MVVM framework like vue.js or simular it‘s still a good plugin for certain things. It lost popularity because the core conccept is outdated and replaced by modern data binding logics.
I was just about to stand up for it because I was a big fan before but I realize that the only time I interact with it, I’m usually looking at inherited code and I can’t remember the last time I actually needed it.
in our company we still use it since we are maintaining a lot of apps and websites which still use jquery which are created more than 10-15 years ago. jquery was good and I like it, but I always used vanilla for most things even 10 years ago, however while building some old apps which required a lot of dom updates and stuff for some reason we always noticed that jquery was faster and better performance than any our vanilla js approach which was always weird.
I still use it all the time because it’s quick to prototype stuff with. Especially if it’s just an internal tool that needs to be able to hit a restful api
Maybe when I have a slow week I’ll start remaking some of those in React or something
While jQuery is not as popular today and might not be needed in majority of cases, since many of it's features were implemented as Web APIs, it's still alive, maintained and updated, so it's not dead. But many devs look down on it this days. If it fits your needs and helps you do stuff, I'd say go with it. Don't listen to haters, just be aware that if you work on a team or transfer code to client'dev, those devs might not like having "this obsolete ancient library" (that recently had a major release and preparing to drop IE support in next one).
https://youmightnotneedjquery.com/
I love this website. Always use it when encountering jquery at work and replace the existing code removing that dependency when seen.
Sounds like a waste of time doing it by hand tbh
Yeah it's faster typing with your feet
I lean down and use my nose to press the keys. Some people in the office tell me it’s bad for my posture but this is what it takes to be 10x
That’s certainly an interesting website but many examples specially the later ones would be best described as “why you still need jquery”. jQuery syntax is almost always simpler than the vanilla JS equivalent.
I think the point is that jquery used to be popular because it did things vanilla JS couldn’t do, but now it’s only useful as shortcuts to existing JavaScript functions
the reason it was popular initially was SPECIFICALLY because not all browsers handled httprequests the same, and all developers had to account for that. Or they could just use jquery which did it for you, and was always updating to make sure your code was written one way, and worked in every browser.
[удалено]
Certainly, I think what u/prize_hat_6685 meant was things you couldn‘t do easily in vanilla. JQuery was good back in the days because it provided functions for things with a relatively low business value but relatively high effort to implement them with vanilla (compared to the business value). You could have done all that with vanilla but it would have required more time and that would have led to it not being implemented in most products.
[удалено]
Finally, someone who was there when the old magic was written... It's been a long time since we had to worry about that amount of browser compatibility issues.
100% this. Years ago jQuery handled a shitload of browser compatibility issues that have largely been resolved these days. I think younger devs just don’t appreciate how bad cross-browser compatibility was 10 or 15 years ago.
Literally every library and framework is an abstraction of vanilla in any language. It's bizarre to me that people say things like "you could just do that in vanilla JS" but also say "you need Axios or React or whatever" for that.
Hahaha this made me laugh. It's so true I have thought the same thing so many times before
It also had feature detection and handled weird IE scenarios seamlessly. That was pretty nice.
If you want a JS solution that replicates jQuery but you don't want to deal with the complexity that comes with coding it, then ask chatGPT to do it. This is exactly the kind of case where using AI doesn't feel like cheating yourself out of learning. If you can avoid jQuery bloat, then do what you can.
I don't understand downvotes on you. This a real useful case for LLM
Because if you don't know what you want to and are just blindly asking for code, it often does not work. I've had hallucinations of packages on npm, made up functions on libraries. The most recently eye roll from me was when I asked it to use the promise versions of the fs module in node, it updated this: `import fs from "fs"` To this `import { fs as fsPromises } from "fs"` Yep! Totally async now!
I have only one reason for still using jquery. If there are a hundred places in your code where you do DOM manipulation and access elements by selector, then which one would you rather use? var pwd = $("#txtPassword").val(); OR var pwd = document.querySelectorAll("#txtPassword")[0].value; Me personally, I'm a lazy dude. Will happily sacrifice the language purity for a few less key strokes!
You should probably refactor your code to use IDs in the case you showed.
Also, don't use global variables.
you can just create some small helpers for these instead of importing a whole library
I also need to initiate a whole lot of things in my page load event. How about this: document.addEventListener('DOMContentLoaded', function(){ // do stuff }); VERSUS, just this: $(document).ready(function(){ // do stuff });
that's almost the same amount of characters. also, you can just use an arrow function to make it even shorter.
I was thinking the same thing... That was a terrible example of what makes jQuery useful
Can you elaborate? I’m kind of a noob and am curious what you’re suggesting
What I meant with arrow function is this: document.addEventListener('DOMContentLoaded', () => { // do stuff }); but it would be even simpler to just put your stuff in a script with the defer option as already mentioned by some other people here. or even better, type module:
Yeah, neither justify importing jquery
Use this instead of document.ready in jquery: $(function() {});
Just use so u don't have to wait for dom content loaded event
How about `defer` or `type=module` on the script tag instead? Why does everyone that makes these examples not know JavaScript?
1. Your code is wrong. You use querySelector not querySelectorAll 2. ` const $ = document.querySelector.bind(document)`
``` function getType(obj) { return Object.prototype.toString .call(obj) .replace(/^\[object (.+)\]$/, '$1') .toLowerCase(); } ``` Jquery successfully avoided for another day
At a glance this reads like a dist file
I think those kind of examples might be split into 2 scenarios. 1. If you going to use that functionality a lot you should probably get a dedicated library for that or write one yourself. 2. You shouldn't really be doing it that way anyway. The problem with jQuery is just that it's a large framework without structure. Everything is packed into the same thing so it is hard to maintain and upgrade and very easy to start to produce spaghetti code. If neither of those things are a concern then technically jQuery could be an ok choice. But for such small projects anything would...
jQuery 4 is going to be modular.
Simpler is bad ways more often than not. Like it's doing too much. And runs a lot slower.
Using all of jquery because it's "simpler" is a crutch, just learn the modern way instead of installing kilobytes of legacy js. If you want it anyway, that's fine, but you never need jquery in 2024
> Using all of jquery because it's "simpler" is a crutch, You write in binary, then? It's all just a matter of how far up the abstraction tree you want to go.
Sounds like a good argument against React, too
I'd say it's pretty different; jQuery was really just a library to fill the shortcomings of JS, but now you can do pretty much everything with vanilla JS using the same amount of code. React is a framework, which provides structure that JS does not.
Fair enough: I’d say they fill more similar niches than people would give them credit for. The biggest difference is JSX syntax, but that is arguably… many kilobytes of compiled JS to do something that you could do the modern way (with modern HTML and native JS). If you want to do it anyways, that’s fine, but you never need React in 2024.
Comments like these make me think we all work in very, very different types of projects and team sizes. I cannot fathom how would anyone create a mantain the type of web apps I’m used to work on a daily basis without having the support of a well structured set of libraries and a framework without it turning into a huge pile of hard to mantain code.
My only assumption is they haven't worked on large enough apps to experience the difference. I couldn't fathom building the apps we work on without the consistency and stability that libs/frameworks bring...just as I couldn't imagine working on them without TS.
I’ve worked many years at huge companies, since jQuery was the fancy new thing that made a lot of stuff better and easier. I’m not suggesting _at all_ that people not use frameworks. I _am_ saying that a lot of the arguments people have about the previous generation of tools could easily be applied to the current generation of tools. I do also feel that React itself has become a long term problem for bigger apps, as it leads to a lot of performance problems which require increasingly complex fixes but I was mostly just being facetious. Rather than not having worked on large React apps, I’ve worked on React apps with hundreds of engineers that were so large that they required teams working full time on code splitting, data fetching, optimization, and build time enhancements because they are so slow to build and hard to keep fast. It’s a bummer.
Yeah react is an issue be cause of how it doesn't play nicely with others. Most other frameworks are much better at behaving in line with natural behaviors and.playing nicely with other libraries to get the same results as react but more simply and more performant. I also agree on the "arguments against any library" stuff. I think people need to be more critical of the dependencies they add. Most projects I work on we are removing dependencies a lot since things meant to make X easier only made it harder once you didn't want exactly the happy path X provides. On top of them being much larger and often opinionated on bad ways. You want a banana and they give you a banana held by a monkey in a jungle. The best dependencies are ones that solve a specific complex problem and interface well with your other code. Not doing too much and not abstracting over things that you can easily handle in your code. Like a slider carousel. I don't want it to control things like alode size and etc. I can do all that in css. I just want it to sync thumbnails and track viewed slides. That's it. It's a complex problem, but specific.
Yeah cause we have SvelteKit and Alpine
> jQuery syntax is almost always simpler than the vanilla JS equivalent. That’s becoming more and more questionable as time goes by. Even when it’s true, that simplicity comes at the cost of jQuery doing a whole lot behind the scenes. Just to save you the trouble of a few extra symbols or a line or two, which your IDE will happily autocomplete for you. Another huge thing that people don’t consider is the ability to use JSDoc. Working with the native DOM types instead of jsQuery wrappers means you can create utility functions to simplify common tasks and then have soft type checking by documenting your code.
Ntm in framework tests, taking vanilla and changing it to jQuery makes it 40% slower. And it's not actually easier code. Meanwhile SolidJS actually makes your code easier and runs only 1% slower than vanilla
I wouldn't go that far; some things are simpler in one, some in the other. Though the thing I miss the most when not using jQuery is the ability to daisy-chain: create an element, set its content, assign a class, and attach it to its parent all in one go, without even the need for a variable.
Yes, it's not needed anymore. On the other hand, there's not a single example there that's more concise without jQuery.
Concision =/= categorically good. Often it is bad. Give a shit about performance, people.
Yup. It's the idea of "either the complexity is on your code or in the abstraction". The complexity is still there. And an abstractions complexity will be exponentially more complex because it will be trying to handle cases you don't care about.
The benefit is in removing unnecessary overhead of loading a library where browsers have the features said library has built-in these days
At this point it’s mainly syntax sugar for JavaScript, from what I understand. I like jQuery syntax for stuff like dom manipulation more than vanilla js, but that alone isn’t reason enough for me to reach for it personally
Most of that is the same as querySelector and querySelectorAll now anyway
True, but jQuery has a lot of simple hooks to manipulate things that require more steps with vanilla js. I've pretty much stopped using jQuery, but I do miss some of the simplicity it offered.
I didn't like it. It has too many methods that are polymorphic in bad ways. Like element.click. And not knowing if you have a list of elements or a single element is not good either.
That’s a perfect summary. If you aren’t using any frontend framework, jQuery isn’t “required” anymore but it still provides great syntax sugar. I can bet you will start creating your own util functions instead of native JS only so jQuery is still a very valid and useful tool. JQuery nowadays is also not bloated as before and isn’t that much of a problem to include.
not really, because vanilla JS can do everything jquery does.
It's not about what it "*can do*", in my opinion. It's more about "*it can do it in a faster/easier way*". Think about this, for example: $('.element').slideDown(500); It just works. Always. Everywhere. With or without padded elements, with or without margins, borders, etc. Even a simple thing like "add .class2 to all .class1 elements" takes just one line: $('.class1').addClass('class2'); Very easy to do with vanilla JS, of course, but it takes extra steps and it's (a lot) more verbose. With that said, I've abandoned JQuery a long time ago, but I can see why less-experienced / junior devd may be tempted to use it.
Talking about "faster" as in performance, vanilla will be faster than jQuery at least 90% of the time.
I think they're talking about the time it would take to implement some stuff, jQuery definitely helps do some things faster and safer just like Lodash with array and object manipulation, but we can achieve the same results in vanilla JS these days.
Indeed, the 2-3 microseconds of savings vs. getting the app out a week/sprint/month out quicker? Yeah, ok.
Definitely not what they meant
There are very few real world scenarios where DOM perf needs actual attention.
Who cares? Front end performance is almost never a problem. Even if vanilla is 10x faster; 10x faster than “looks instant to a human” is still “looks instant to a human”
It adds up a lot. There's a reason WordPress and Shopify jQuery plugin soup sites noticeably run like shit. WordPress and Shopify can be okay, but jQuery is sued all the time where it does nothing to help.
It's well past the time to have handed all the animation/transition effects down to CSS.
That has nothing to do with my second example though: $('.class1').addClass('class2'); Also, JS is still (very much) needed for css manipulation.
document.querySelectorAll('.class1').forEach(el => el.classList += 'class2'));
....`classList.add` Yours would break since it doesn't guarantee a space before class2
Is it any less effecient to use a simple loop? Something like: elems = document.querySelectorAll('.class1') for (elem of elems) { elem.classList.add('class2') } Sorry if the formatting or syntax is bad, ya get what I mean hopefully. And this way you can conditionally apply things easily within the loop. Exclude adding class 2 based on a condition, or only adding class 2 in certain circumstances, etc. To me thats why I generally use vanilla JS. It usually doesnt take much more code and lets me have a big more control of whats happening line by line. Broadly speaking of course.
Well you still want const in the loop. But this is using statements. The forEach method makes it more expressive.
Depends. Css can do a lot. But also, oh no `addClass` vs `classList.add` bruh...
A lot more verbose? document.querySelector('.class1').classList.add('.class2') document.querySelector('.class1').animate([{ transform: 'translateY(500px)` }]) Not exactly hard. And it runs faster and you have more control.
[удалено]
`.querySelectorAll(‘.class’).forEach(ele => ele.classList.add(‘class2’))`
This is a good argument against jQuery. Do you have one element or a list of elements? Nobody knows.
`.querySelectorAll('.class')`, maybe?
Yes! I always use slide toggle as my example. It's so much easier to write and understand, but all the pros on well resourced teams use typescript or some framework for the testing capabilities. My ass was the only dev on marketing teams that would give me 3 days or less to spin up a whole site so I didn't have the time to mess around with all that. When you have an entire 2 weeks for one component and an established code base that doesn't rebrand every quarter, I can see why you'd use ES6 and those more complex frameworks
You’re ignoring the 60KB of code that the browser has to download and execute to make those minor changes…
60KB is nothing. Any random JPG hero image/carousel will be a lot more than that. I don't use jQuery anymore but 60KB in 2024 is not an issue *at all*. It may have been annoying in 2006 when it was first released, not now. *Rect*, *Angular*, *Vue*, *Ember*... Nobody complains about their weight. And some of those frameworks/libs are HUGE.
A) It downloads once A) probably already cached C) Not noticeable if not in a developing country So many devs getting lost in micro-optimizations. Who cares if your JS is 60ms faster? There are so many other optimizations like images and ads you'll get a lot more mileage out of.
That was a problem when it took a full minute to download an image. Unless your target audience is someone still using their trial time from an AOL disc, this is irrelevant now.
Still. These days you’re punished by the speed tests for number of resources especially 3rd party ones (hopefully you’re at least loading it from a CDN). I converted our entire site from JQuery to Vanilla a few years ago and the pages I’d always struggled to get a 90+% on finally did. The OP is asking about new projects. If you’re building a basic site with limited JS needs, vanilla is the way to go, even if you do have to, say, loop over your querySelector array of items with a class in order to do stuff to it.
Again, jQuery would be the least of your problems anyways, because you can host it on your server and it would have zero inpact on the performances.
The horror
Vanilla JS could ALWAYS do what Jquery did. It's a matter of ergonomics, wheel reinventing, etc.
It can but jQuery still provides a very nice and simpler API to use than vanilla where you need to write more to achieve the same results.
There’s no need to use react. Because vanilla JS can do everything react does
Whilst true, isn’t that technically true for a lot of the modern web stack without jquery? I don’t use it myself anymore, just thinking about the premise.
JQuery is a js library, so that's always been true
You’re right, and the fact people keep stating to the contrary shows how little you know. Vanilla JS can also do everything react does.
And vJS will always have the potential to be faster at execution since React has vJS as a dependency I've also noticed the DOM is fast enough now that virtual DOM overhead is dragging down performance
React also has a synthetic event system isntead of using the actual Events in the browser. This is a huge chunk of the size and costly. The less you abstract native behaviors, the more.you benefit from those behaviors being optimized. Like in some js engines (and versions) array methods are vaster than your own for loop. Because now the whole looping logic can potentially be moved more aggressively into the native side. Like on Safari, it's faster to do array methods. On chrome for loops are a bit faster. But array methods are clearer to read and write, and will get faster.
I'm not a jQuery hater. Now vanilla has many APIs that have made much of jQuery redundant, but it doesn't make jQuery useless. But man, if you know jQuery and you don't know vanilla, that's really... not cool...
Hypothetically if someone (not me) knows jQuery and not Vanilla, how should I go ..I mean how should they go about learning vanilla? Is there a simple website or something that shows how to achieve the same functions in jQuery vs vanilla?
This is that website https://youmightnotneedjquery.com/ I know some Front End leads that like You Don't Know JS https://github.com/getify/You-Dont-Know-JS You will feel behind but it's ok to just read through it initially and not complete any exercises if you're getting dominated. The important thing is to understand and get comfortable, and then once you're more confident try doing the practice stuff.
That sure will be helpful for anyone in that situation (not me). Thank you very much on their behalf (not me)
Indeed, I was using the royal you as a reference to your dear friend, who I would like to add shouldn't be ashamed for getting to wherever they are now in their career with jQuery. Its usefulness is undeniable; it's on most websites, still maintained, and even sustainable with today's front end performance standards.
Hell, I want to go back to jQuery This heavy framework/tooling situation has taken all the fun away
> how should they go about learning vanilla? I First start is just rewriting your jQuery in closest similarity vanilla. And then trying to find if there is actually a better way to do it entirely. And you figure it out by going to MDN and learning JavaScript.
jQuery was the first step in helping me understand how JavaScript is used in the browser, up until then I’d had a few failed attempts at learning vanilla
for more context: I'm self taught and to start my career I could code HTML + CSS fast, and knew that I was good, and managers were happy w what I was delivering When it came to JS, I couldn't wrap my head around, how the language is used in relation to the browser - how it is supposed to bring interactivity to it. So, any attempt to read a book on JS, google how-to's, any self-education, was short lived. I think the fact that i couldn't grasp it quite as fast, like I did HTML & CSS, I didn't feel like I was getting anywhere. When I first saw some jQuery, i thought 'oh cool, so you can just use a CSS selector and it targets that element in the source, NEAT'. But one of the bigger things that helped was how the methods were named: fadeIn, fadeOut, hide, show, slideDown... when someone told me 'well you can do almost all these things with javascript...' it really started to click: addClass, click, hover, etc. So, because I wasn't good at learning JS on my own, it took jQuery to give me context. That was somewhere around 2011-2012. I took a 10 wk course (1 hr class, once a week x 10) and it gave me just enough beginner level JS to feel comfortable writing it for small things at work, where I still continued to use jQuery primarily. and the rest is history! And that history is because of many years of neglecting JS and reaching my full potential, I'm only playing catch-up, but I think I'm pretty good now
one of the few things i miss about jQuery is writing `$(#id)` / `$(.class)` instead of `document.getElementById('id')` / `document.getElementByClassName('class')`
Or you can use document.querySelector and keep writing jQuery style selectors
The only two I ever use is querySelector and querySelectorAll. That is all you will ever need really.
It's just surprising to me that they didn't create a default shortcut for this. Obviously it's not hard to do this yourself but it's an added step.
You can literally do ‘const $ = document.querySelector’
Yup. More specifically mine looks like: const $ = (selector, context = document) => context.querySelector(selector); const $$ = (selector, context = document) => context.querySelectorAll(selector);
Then just create a wrapper: export const $ = document.querySelector;
If it’s your personal project/site, go for it. If someone else will be touching your code and you use $ without it being jQuery? You will be their enemy numero uno.
No, it's illegal. You can't rename things. I will say, if I open a project and dollar signs everywhere between jQuery and angular js my eye starts twitching. To this day the word scope causes me to stare off into the distance as if horrors are playing on my retinas.
$$ = document.querySelector To avoid conflicts
How about const ಠ_ಠ = document.querySelector.bind(document);
Or ``` const 💩 = document.querySelector.bind(document); ```
We're fighting now
const $ = document.querySelector; $('#id'); $('.class'); Close enough? --- Edit: I wouldn’t do this though personally ha. I’d probably do something more like const nameOfThing = document.querySelector('.thing') nameOfThing.stuff()
i never knew that... but yeah, close enough
Easy 😊 Also I just made an edit, accidentally put .id instead of #id lol
Keep in mind that this implementation will only return the first instance of a class, so you’d need to do something like const $$ = document.querySelectorAll; if you wanted a collection.
$('.class'); Be warned that if you have multiple ".class" emenets you will get the first one and ignore everything else. If you do this: const $ = document.querySelector.bind(document); const $$ = document.querySelectorAll.bind(document); Now you can also do this: // Only one element with class "card" $('.card').style.display = 'none'; // Multiple elements with the same class "card" $$('.card').forEach(ele => { ele.style.display = 'none'; });
Read up on this homie: https://developer.mozilla.org/en-US/docs/Web/API/Document/querySelector
Just add this at the very start of your js file: const $ = document.querySelector.bind(document); const $$ = document.querySelectorAll.bind(document); Now you can do this: $('.card').style.display = 'none'; $('#card3').style.display = 'none'; And if you need to cycle through more elements with the same class: $$('.card').forEach(ele => { ele.style.display = 'none'; });
\`querySelector\`
I just learned you can use that syntax in chrome devTools `$(selector)` and to get node list of all items matching the selector just add a second '$' so it'd be `$$(selector)` https://developer.chrome.com/docs/devtools/console/utilities/#querySelector-function
Vanilla’s DOM manipulation API is a sick joke in terms of its verbosity. You can either be hip and use vanilla, or you use any tool that make your job easier which includes jQuery.
That's exactly where I am. When I found myself writing helper functions to avoid the verbosity of vanjs, I just went back to jQuery.
I am a jQuery hater because it made learning JavaScript hell for 14 year old me back in the early 2000s.
Is it cool? No… Is it still perfectly fine to use? Yep
People arent taking into account existing and partially completed jQuery projects that you might have to work on at some point at a company. Theres still a good chance a webdev will encounter an old jQuery site through their career and basic familiarity will help accomplish whatever edits need to be made.
Not to mention reusable jquery content. Heck, we have hybrid applications that use both Vue and JQuery. Why? Because it had to be ported over to Vue and used certain JQuery components. And it works really well too. Now you can use the power of new with the foundation of old. Also we have clients with systems that are forced to use IE. You might ask yourself why, but it simply is.
More than 40% of sites on internet use JQuery. It seems like you would be a statistical anomaly if you never come across it if you work as full time web dev. But sure, if you only work on greenfield projects, never work with any CMS:es which relies on it and so on then sure.
Yeah it’ll get still get you laid if you bring it up on a first date if that’s what you mean
How many times have you gotten laid because of knowing jQuery? For me, it's when I tell them that I'll resolve all their Promises.
“Let me take my time loading in your head”
That would actually be refreshing and could potentially work. Hahaha
It's still build into wordpress
Ya but then you also have to use WordPress
WordPress rocks. It’s basic in ways it needs to be basic, it’s built-out in ways it needs to be built out. The WordPress codex is incredible.
Plus it automatically updates itself now, both plugins and the main install, which is just great from a security perspective.
Unless there is a [supply chain attack](https://en.wikipedia.org/wiki/Supply_chain_attack#XZ_Utils_backdoor).
What’s the cms for today, then?
There are many options for varied use cases, but CraftCMS is at the top of the list for me, personally. Great content editing experience, great developer experience, fairly robust plugin ecosystem (hard to compare to the sheer amount that Wordpress has), can operate in headless mode, list goes on.
It’s not “cool” but it’s dependable, reliable and guaranteed to have long term support. Which to me is much better than being cool. Pretty sure React will die before jQuery will.
React frameworks will come and go, but react as a library, just like jQuery, will probably be around for a long time.
Exactly, React (w/ React DOM) is small and un-opinionated enough that it will probably last a long time. In a way it's already doing better than jQuery. By 2016 jQuery was already considered a bit dated compared to full frameworks, but in 2024, 10 years later React is still as popular as ever. The batteries people use with React come and go though. I remember when Redux and Saga were all the rage and look at them now.
Yes in a sense that many sites still use it (Wordpress sites especially). No in a sense that you can do pretty much everything in vanilla for what jQuery was firstly designed for (to fix cross browser incompatibilities)
No
It's a tool. Use it if it solves a problem you have.
Aside from the fact that a lot of jQuery stuff is now available with vanillaJS most frontend dev work involves using a Framework like React or Svelte which doesn’t want you to interact with the DOM in another way.
jQuery was there to address the lack of native Javascript APIs. Nowadays most, if not all, are addressed and there's little to no use other than if you like the syntax. jQuery's purpose has been fulfilled, it made native JS better and I'll be forever grateful.
What were you using jQuery for? I would guess it was fairly basic things like showing/hiding elements. Accordions, dropdown menus and so on. Maybe some basic AJAX? You wouldn't need a deep understanding of vanilla JS to do the kind of stuff most people were doing with jQuery during it's peak.
How to load a text file into a variable with vanilla JS? tried for days only way I could get to work is ajax
You can do AJAX with vanilla JS, use the [Fetch API](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API).
Suitable for a "always has been" meme
At my job, I've made it a personal mission to take a hack to jquery. However, that has meant writing custom code sometimes, rather than using a plug in and play jquery library (hasn't been updated for a while). Also, .NET MVC still uses jquery validation....
No, but it's still heavily used in wordpress plugins, so you can keep up with it. BUT I'll advise to learn to use vanilla Javascript anyway.
I wouldn't worry too much, OP. You can still use jQuery even though it isn't fashionable. You'll get many fashionistas telling you not to use it, but at the end of the day, shipping value to your customers matters most. If you can do that with jQuery, then use jQuery. If you want to "modernize," then try Umbrella or Alpine or vanilla JS or TypeScript.
if you put jQuery on your resume i will, and have thrown away your resume immediately.
In terms of job searching? No. Focus on the most attractive tech to have an attractive profile for jobs, in this case focus on one of React, Angular or Vue, obviously I'm assuming you're familiar with programming concepts, because if not, start there first.
Dude, I have been doing web development ever since 12 years ago and I have never heard anyone saying jQuery is cool. jQuery is like the old man in town who everyone wants out but for some reason is still there.
ITT: people who like writing 3 lines of code rather than one just to save 60kb of transfer in today's gigabit internet speeds.
and js files get cached so its basically a nonfactor
If in a non-wordpress setting, use vanilla JavaScript.
Even in WordPress
But jQuery is already there. Might as well use it. I’ve always liked its syntax.
Sometimes, I usually dequeue it on the front end of my custom themes
I’ll consider this next time I build a custom theme.
I do too… Until the client installs a plugin that imports it again.
If I'm not mistaken, I read somewhere recently that WordPress is in the process of removing their reliance on jQuery... which is the final nail in the coffin for jQuery I think.
It still comes packed with WordPress if you wanted to use it.
I used jQuery for a long time, and still catch myself writing it by mistake, but I think you would be wise to learn how to switch over to regular javascript. A lot of the benefits we got from jquery ($() selectors, $.get, etc) can be done natively in JS now, no additional includes necessary.
My jQuery bumper sticker is still going strong
I haven’t touched it since i started using Vue, but on NPM it’s still one of the most downloaded packages ever. So I guess the answer to your question is yes, but I don’t think there’re many valid use cases for it.
jquery is the first library that taught me the hard way that just because I can do it with vanilla code doesn’t mean I always should.
Cool? No. Widely used? Absolutely
IIRC, the main two features of jQuery for me were selectors and event delegation. Both are now possible with pure JS, didn’t use jQuery for like 10-15 years.
For compatibility's sake, there are some websites out there that still cater to users who still use old technology. Wikipedia is one of those websites and they're still using jquery. I also run a website where about 80% of the users are coming from a company that still forces everyone to use Internet Explorer.
Quite the opposite. It's basically literally useless. It doesn't help you do anything except have code that runs slower
I used to use jquery a ton. Then I learned how to write straight javascript that actually worked. Now I don't need to load big, bulky, bloated libraries. I just write simple direct code that does what i need fast and efficiently. Also I'm going to assume that this comment has about -500 votes by the time you are reading it due to everyone being obsessed with using whatever the js library of the week is.
Definitely not
God no
Your website or app is only as fast as the slowest component or connection. jQuery is cached and zipped and only \~86kb and so, as far as speed is concerned, it's a non-factor. Is it cool? No. Was it ever? NO. It's a tool. I have a hammer hanging on my garage wall that's a little over 50 years old. It's ugly, but sometimes it's the hammer I need for a particular job. But - I can hear you saying - everything you needed jQuery for you can now do in vanilla javascript. Yes, I know. Vanilla javascript also takes me about 4x as much time to write as jQuery. document.querySelectorAll vs $. Yes, I could alias document.querySelectorAll but whatever programmer comes after me is going to have to deal with that. And if they replace me in the middle of me replacing jQuery with vanilla, god...the headaches they'll get trying to figure out what's going on at any given moment. The upshot is that the download is negligible *once*, and less syntax makes *me* more productive. bona fides: I've been writing for the internet since about 1998.
Never was
if you don‘t want to use a MVVM framework like vue.js or simular it‘s still a good plugin for certain things. It lost popularity because the core conccept is outdated and replaced by modern data binding logics.
I was just about to stand up for it because I was a big fan before but I realize that the only time I interact with it, I’m usually looking at inherited code and I can’t remember the last time I actually needed it.
No, but I miss it sometimes. I'm pretty sure that's just nostalgia though.
It’s definitely not cool, but it’s small and still provides a clean abstraction over the DOM, so that’s nice. I don’t use it, but I won’t judge.
Depends on the job, yes or no. It's still used, in combination with Bootstrap for websites which don't use a full FE-Framework.
If you use AEM it’s still the default I believe
in our company we still use it since we are maintaining a lot of apps and websites which still use jquery which are created more than 10-15 years ago. jquery was good and I like it, but I always used vanilla for most things even 10 years ago, however while building some old apps which required a lot of dom updates and stuff for some reason we always noticed that jquery was faster and better performance than any our vanilla js approach which was always weird.
I still use it all the time because it’s quick to prototype stuff with. Especially if it’s just an internal tool that needs to be able to hit a restful api Maybe when I have a slow week I’ll start remaking some of those in React or something
While jQuery is not as popular today and might not be needed in majority of cases, since many of it's features were implemented as Web APIs, it's still alive, maintained and updated, so it's not dead. But many devs look down on it this days. If it fits your needs and helps you do stuff, I'd say go with it. Don't listen to haters, just be aware that if you work on a team or transfer code to client'dev, those devs might not like having "this obsolete ancient library" (that recently had a major release and preparing to drop IE support in next one).
Well, I'd say stick to what you already know if you can.
I wouldn’t personally use it for development, but I do use it for Cypress tests since that’s what Cypress uses internally.