When I first started programming I was pretty lucky to get a job at a games company. My first lead was a veteran who had shipped a lot of AAA titles and he loved his war stories. He was personally interested in performance and he would often cite hardware timings for specific cpu instructions.
One story he told a couple of times was about some grey beard who was before his time. The grey beard was once a legend in the company, often helicoptered into projects at the last minute to help them squeeze out the last bit of performance. His secret was he had a mental library of assembly language tricks applicable to the hardware of his day. But every few years his tricks were less and less relevant as hardware changed and compilers advanced. One day the grey beard was helicoptered into my leads project and everyone expected him to get them some gains. However, this was new hardware and none of his old tricks worked.
I think of this story whenever I see jQuery popup on Hacker News. There is always a strong contingent of devs who swear by this library. But to me, they are like the old grey beard who didn't update his knowledge as the times changed. At one time jQuery allowed them to be the hero and "Get Things Done" faster than their competition. But times have changed.
Argue with me if you must but take stories like this one for what they are worth. The writing is on the wall for jQuery. I was writing websites before jQuery existed, during the reign of jQuery and still today. If some candidate mentioned proficiency with jQuery during an interview I would be polite but internally I would note that the person might be out of touch. Not a red flag, but a yellow flag that I would follow up on. Nothing worse than bringing on a guy who claims to be senior/experienced and it turn out his old tricks won't work because they are no longer appropriate.
> But to me, they are like the old grey beard who didn't update his knowledge as the times changed.
Maybe it's just me but with all the rampant age discrimination nowadays in tech, I really don't like to see the continued propagation of this stereotype.
All sorts of people of all ages are unwilling or unable to update their knowledge of new tech, there is no reason to link this characteristic to someones advanced age.
This is a fair criticism of how I chose to tell the story. The line you quoted was supposed to refer to the character introduced in the second paragraph and not to a generic stereotype of aged man.
I can see how my choice of wording created an implication that people who have grey beards are old and that it is this oldness that contributes to their unwillingness to learn. The familiar cliche of "you can't teach an old dog new tricks".
What I actually hope to communicate is that there is a hubris which leads some to believe their skills do not require updating. The caution is that sooner or later this hubris may lead to sudden downfall. People may call on you in their time of need and you will fail. And this failure is not because of your age, your intelligence or your willingness to work hard. You will fail because you became overly comfortable with a passed status quo and you let your skills get out of date.
I see a trend of well-written, evidence backed articles where large, well funded sites are making a case to deprecate jQuery. These fact-based investigations into problems faced by their dev team result in a reasoned decision to remove a dependency that no longer justifies its cost. I encourage everyone to introspect if their defense of jQuery is on an equal technical footing to these types of investigations.
I sympathize with older devs, my dad is an older software dev.
But you kind of do have to be old in order to have outdated knowledge: nobody young is going to learn assembly tricks which worked on MIPS and other past architectures. Older devs and companies not constantly learning new things and updating to best practices is a real phenomenon.
On the other hand, anecdotally most older developers actually do keep up to date with the latest best practices. And there are lots of decades-old frameworks which aren’t obsolete: lots of people greenfield projects with C++ and Spring Boot and .NET, and unless I’m mistaken the C ABI and system calls haven’t changed much over the past ~40 years. So it's not like being old automatically means or even really suggests you're going to use worse, outdated techniques.
What I have seen is awkward situations where you have two developers of roughly equal competence. One happens to be 45 and the other 28. Fine, nobody would care about that. Except that due to automatic annual raises, job switches, seniority bumps etc, the 45 year old developer is paid twice as much as the junior.
The rational response to this would be to say to align the two salaries (probably somewhere in the middle), but obviously the older one is never going to accept that - we all expect our salaries to "ratchet" upwards. So we end up with the irrational response, which is to sideline/kick-out the old expensive developer
I have found the opposite of the stereotype to be true; I feel I've learned more in the last 5 years or so than I have the previous 30 because I now have the experience to contextualize and sort it all, the discipline to stay focused and active when Real Life doesn't want to let me, and access to resources that would have cost an unreasonable sum even 10 years ago.
>> But to me, they are like the old grey beard who didn't update his knowledge as the times changed.
> Maybe it's just me but with all the rampant age discrimination nowadays in tech, I really don't like to see the continued propagation of this stereotype.
I would agree. If you last a long time in tech, you're more than the sum of the libraries you've learned.
Taking the age factor out, I have seen time and again senior level devs that have outdated knowledge and are, alas, not functioning as senior devs any more. This is not just in frameworks, but also in design and methodology. Once they reached a certain level they got lazy and decided they were good enough to stop learning every day.
>All sorts of people of all ages are unwilling or unable to update their knowledge of new tech, there is no reason to link this characteristic to someones advanced age.
In 1998 I was in a web development class with a guy, and one time I went by his house and he showed me his little resume site he was working on. It was really nice looking, he had a great sense of design, I could have made it but I couldn't have designed it. But it was all table based, so I showed him CSS and extolled its virtues.
After which he exclaimed furiously "That's the problem with this industry, there's always new things to learn!"
He was just starting out and was already unwilling to update his knowledge of new tech!
I think he's working as a SiteCore admin in Dental association now. I'm pretty sure he has a nice work life balance, so make of that what you will.
Also, with the kind of smug tone op has posted his comment, I'm reasonably sure he doesn't understand that basic techniques fir x86 optimization have actually remain largely unchanged and what worked then also works reasonably well now, despite compiler improvements
I think you're greatly exaggerating the death of jQuery
> old trick's won't work
> writing is on the wall
jQuery still works and is used in an crazy amount of websites. It's not going away soon. The biggest downside is the extra network request, but it's probably cached in 99% of browsers, so all that's left is some extra CPU time.
You're also exaggerating the claims of jQuery defenders. No one here is arguing that the site should keep jQuery, or that you should write a ton of new jQuery code.
Chrome started partitioning the cache a couple years ago to mitigate timing attacks, so there's no network savings anymore when a bunch of sites all link to the same jQuery cdn entry.
Absolutely. I stopped using actual jQuery a while ago in favor of a light (78 loc) wrapper around the native DOM that mostly uses the jQuery API. jQuery has a really well thought out fluent API.
Exactly, I don't know why people have to pit jQuery against the current generation of ui or vdoms etc. Just because you have a car doesn't mean a bike doesn't have its uses.
> I think of this story whenever I see jQuery popup on Hacker News. There is always a strong contingent of devs who swear by this library. But to me, they are like the old grey beard who didn't update his knowledge as the times changed. At one time jQuery allowed them to be the hero and "Get Things Done" faster than their competition. But times have changed.
Whenever I want to use "vanilla JS" I use jQuery, because I find the DOM and various other JS APIs quite annoying to work with and jQuery makes things a lot smoother. There are some other, slightly smaller, libraries too, but they offer little advantages, are often unmaintained, and many people at least kind-of knows jQuery.
Bombastic absolute statements about "greybeards" being "out of touch" etc. is basically why I tend to avoid the JavaScript frontend community by the way, and also why I moved towards backend rather than frontend. I'm too old to deal with people who think there is One True Way™ to do things and that everyone who disagrees is a blubbering idiot (not that FE JS have a monopoly on this by any means, but it's far more common there).
Yes as a "greybeard" i noted first that the headline performance gain was 10% & 11% this for a team given far more time and resources to optimize for their goal than most teams or individuals dev. I raised an eyebrow at that
However devs seeking employment should always be prepared to play up to what is trending vs what is appropriate.
I wish JS would get all the nice jQuery features, like all the css selectors jQuery has, like a nice feature would be when you retive an HtmlElementCollection to be able to apply some transformation to all elements without having to write a for, or make use Array.from and then use forEach.
But I agree I would not use jQuery in new project and when possible I would replace jQuery in existing code too.
That's what everyone keeps missing. Can vanilla do what jQuery can? Of course, and that has always been true. What jQuery (and similar) offer is quality of life stuff, vanilla has never even tried to offer.
This is still an ecosystem without a standard library and with no consistent design style/layout. It is janky and bad. It being "less bad than it used to be" isn't the shiny endorsement that everyone thinks it is.
> to be able to apply some transformation to all elements without having to write a for, or make use Array.from and then use forEach.
This has worked for many years. I typically add a shorthand $ for the QSA part and on projects where I used to support IE11 you could add Array.from there but I haven’t bothered since IE was deprecated. jQuery does more but some of those things had performance impacts which were worth thinking about and the combo of QSA and fetch took care about about 90% of my projects.
As a counterpoint, I had a similar conversation with a report of mine about jQuery. He said it was not necessary and you could just use vanilla js.
I said while yes that's true as a dev if I told you I needed you to implement a new payment provider for billing would you tightly and directly align with who we used or abstract it away via some wrapper so that if we ever had to change it wouldn't be difficult? Of course everyone builds abstractions so you aren't stuck with a single provider because it's crazy not to.
I see jQuery as that abstraction. At the end of the day each browser is an api implementer and while they've come so far, that doesn't mean the situation is stable and we'll never see implementation fracture again. It of course doesn't have to be jQuery but any direct implementation of JS seems to have that risk which is easily mitigated by wrapping the basic functionality. I don't know why you wouldn't choose to do it.
jQuery was a useful abstraction when browsers had inconsistent and clunky apis.
Modern browsers have apis that are about as convenient as jQuery's, are standard across browsers, consistent with the language, and guaranteed to outlive jQuery the library. Aside from dot-chaining in a monadic sort of way, jQuery offers no benefit to the developer, while costing about 30kB of javascript.
The problem is that most of the "abstractions" provided by jQuery are no longer abstractions and can frequently be replaced with simple alternatives that are directly provided by browser APIs that have extremely wide support.
Amusingly, I always joke that I'm fluent in jQuery, but no absolutely no javascript. As a mostly backend go/python/non-javascript developer that has always held true.
It is just a tool in the belt for an engineer. Can you use jQuery in 2022 or later to solve really amazing problems that impact user experience? You sure can! Would you be better off to use a modern javascript variant and stuff like react instead? You also absolutely would.
So just because a tool is old doesn't mean it can't be used to solve real user problems. There are still banks and airlines that run COBOL, and as a user, do you really care that much? I'd take "knows $insert_older_less_hip_tech_here" as experience of having done something for awhile.
Now if I was asked to write a front end today, I'd have to sit down and properly learn react + typescript (because javascript is awful without sensible type checking), and that would add to the time to ship, but is the correct thing to do.
While I think that’s the right choice, I’d just like to point out that the problem with jQuery today is it was a library built to smooth over and fix differences between browser JavaScript engines (IE, well, IE).
Over the past 15 years or so browser JavaScript engines, except at the extreme edges, are roughly comparable. Further, a lot of the features of jQuery have been adopted into standard JavaScript.
So, the reason of eschewing jQuery, even for small pages, is simply that you don’t need it. Vanilla JS (or typescript) + modern CSS have pretty much all the same capabilities without any of the bloat. Using it today would be a little like using a library made to back port java 8 features onto a java 5 JVM.
> Now if I was asked to write a front end today, I'd have to sit down and properly learn react + typescript (because javascript is awful without sensible type checking), and that would add to the time to ship, but is the correct thing to do.
It really is enjoyable working w/ react+typescript. :)
It's pretty expensive to ship and compute. Wikipedia for example dropped jquery from their navigation and it resulted in a ~27% difference in battery usage IIRC.
I checked out kubirds, and even though I'm probably somewhat in your target demographic, I noticed that I couldn't discover what kubirds does without watching a video.
Even scrolling down, and through the website, I didn't really understand it, until you compared to Nagios, which I am familiar with. Hope you don't mind a little unsolicited feedback. The website does look super clean!
I would love to read a paragraph of your elevator pitch the moment I lay my eyes on the site though. Cheers.
> what's so wrong about sprinkling some jquery on a static website
You're talking past one another. He's speaking in the context of AAA games, and the equivalent of that in the webdev world is a highly interactive application.
For everyone of these "grey beard" stories I can point you to a "young gun" story involving a fad of the week framework that's just over complicated and over engineered and doesn't even solve anything.
A long time we had a really good engineer who can crack topcoder and coding challenges with ease. We had a problem where we had to collect all changes to the User models and send it to the marketing platform. It was initially implemented in Rails Active Record which took progressively more time to collect and sync changes. Rails was hot at the time and SQL was really frowned upon. A lot of developers to this day hate SQL. Then came a "grey beard" who simply rewrote the whole thing into a single complex query that let the database figure out the optimum way to find the exact same data. Total time went from over 10hrs to 10mins.
I fall in a different camp. If somebody proposes to use a brand new hot technology in a project that is planned to exist more than a few weeks, I tend to politely stop them in their tracks and use a stable reputable solution proven by time.
You see, new hot technology is always replaced by another newer hot technology, and after hotness wanes, projects often become a abandoned and unmaintained.
Extra this if the proposed hot new tech comes from Google. In this case person pushing it should not only be stopped, but also slapped hard, to help come back to senses.
While I agree to some extent, jQuery is so prolific online [0] there will always be jobs for those “grey beards” who know it well. There will always be legacy codebases that make extensive use of jQuery that will never be rewritten and are too important to retire.
jQuery is the new Cobol!
I’m not a “grey beard” but I’m currently doing a freelance project updating the UI on a Perl+jQuery site… As much as we would like to rewrite it from scratch it’s very unlikely to ever happen, it’s going to be maintained as is with small steps towards “modernisation” over time.
0: jQuery is used by between 15-40x more sites than React depending source:
To be fair, vanilla JS, especially document.querySelector, still hasn't caught up with all the features of jQuery and any other framework is going to be much, much bigger than jQuery.
It's not COBOL until something replaces jQuery that is easier than jQuery.
Jquery devs prob don't deserve as much credit as your old greybeard. And jquery was moreso used for browser compatibility and ease of use than performance or so I recall. On the topic of performance in web frameworks I often have to hear people tell me react is faster than plain vanilla Js. I used to argue the point but now I just smile and nod. Maybe the world has gone mad or maybe I'm the one out of touch
Speaking of gamedev and jQuery, I work at a company where we basically make games for education purposes, for high profile universities, mostly. The games are all web applications, and we've learned to bend React in each and every direction to best serve our uncommon use case. A few months ago we needed some extra firepower, and offloaded a project to a small team of external consultants. I'm still shocked by what they shipped: the smoothest and juiciest web game I've ever seen, made with the messiest and most ancient clusterf€#k of jQuery I've ever witnessed in existence.
The moral of the story to me is: no matter how cool your new shiny tool is, old, battle-tested tools have generated generations of wizards which, given the right scenario, can still bring magic to the table.
The part you're leaving out, is that once confronted with the fact that his old easy tricks don't apply, the well-seasoned fellow will draw on his years of experience to provide new tricks to save the day.
I think your portrayal of well-seasoned engineers as the derogatory 'greybeard' with a 'bag of tricks' and a hero complex -- glosses over the fact that many of these men and women have real hands-on experience with a multitude of technologies spanning decades, and in my mind there's real value / leadership qualities associated with individuals companies can rely on to just "get things done" in a pinch.
Your examples (while beautiful) are fairly different from each other.
The assembly tricks got obsoleted because they're not needed anymore - we simply don't program in that hardware anymore.
jQuery still works fine to this day. It's just that engineers don't like it anymore. The same will happen to React in a few years.
I wouldn't hire a jQuery developer for working in a cushy company with their millions and their React codebases - React knowledge is actually one of the things we test for (and, unexplainably, one of the few exceptions we'll allow to avoid knowing about algorithms and time complexity).
If I had to build something with my money on the line, I'd definitely pick the jQuery veteran.
Recently I helicoptered into a call with three developers trying to execute a database upgrade and it seemed to be hanging. I joined the moment when they wanted to interrupt it and try again for the third time.
Only thing I asked was, if something is locking the schema. Then I left to another meeting and I saw them exchanging statements to find locks and delete them in the chat. Turns out there were long running queries hanging that nobody seems to care about. To me it's hard to believe nobody has configured a query timeout on the database
I'm not sure it was ever a particularly reliable approach to master instruction timings as these timings are a best effort schedule guarantee outside of a hard real-time system. Unless you profiled each instruction cycle timing over every microcode update to your processor, maybe, but I'm doubtful this was ever a sound approach.
It doesn't sound like grey beard knew what he was actually doing, but more relying on his years of experience and good fortune that has kept him with a job up until then.
I agree with your sentiment in total, but I'd also add, for every out of touch programmer still swearing by JQuery, there are 5 recruiters that demand proficiency in it that other programmers feel they need to appease.
I think the most diplomatic way of distinguishing the two types of programmers is just to ask why they like JQuery.
"Because it helps me ship faster" may be a bit out of touch.
"Because it's a required competency in working with some code bases" are probably the latter.
Why should we have to uproot everything we know for the flavor of the month??? No other industry does this! You can work the same job for 45 years in any other role
Tangential, but sometimes I see people say that jQuery is dead/failed. While it's not as popular anymore, I think that's actually the perfect evolution for it. jQuery was making up for browser API shortcomings, and now many of those shortcomings have been addressed and been incorporated into browser APIs (not everything, but quite a bit).
> jQuery was making up for browser API shortcomings
While this is true, I can still code circles around frontend developers using vanilla JS.
The decline of jQuery is mostly due to the rise of webapp frameworks like React and Vue. But if you are tasked with adding like, a button to a static webpage, jQuery is still the king.
I never really knew jQuery besides the five things that I googled, so once I had to do more "dynamic" frontend things I just looked into Vanilla JS and it kind of works for me. Not sure if I had WTF-moments besides the normal "this seems to be how things work" stuff, so I think it's easy enough?!?
Only thing I always have to look up is how to make sure my script is executed once everything is done and not before and "ready()" is obviously easier than adding an event listener to "DOMContentLoaded". Yeah, had to look it up for the comment.
>The decline of jQuery is mostly due to the rise of webapp frameworks like React and Vue.
Partly. Frameworks like Angular/React/Vue are a necessary byproduct of building and maintaining large codebases. But the fall of jQuery was largely a result of a more standards approach in mainstream browsers (said another way: deprecation of IE and not needing to work at maintaining consistent behavior across browsers), as well as adding traditional jQuery-like features to vanilla JS.
There really isn't a big use-case for jQuery anymore, although I will remember it fondly.
>While this is true, I can still code circles around frontend developers using vanilla JS.
My first use of jQuery was in the dark days was building UIs (with things like drag and drop, etc) that had to run on Internet Explorer and Netscape. We'd started with "vanilla" but were ending up with what was effectively two separate codebases. Moving over to jQuery let us eliminate a massive amount of duplicate code and dramatically increased our productivity.
When people have said this to me in the past I would trot out a list of features that were still useful, but there are one or two where I think the defaults are backward. There was a long time between when "jQuery is dead" and parent selectors of any kind existed, and list comprehension is still a huge miss.
I still wonder occasionally if there's a place for a library that works like a strict subset of jQuery, but with different error/empty set handling defaults. Especially with list comprehensions. I found that 9 times out of 10 if I run a selector I'm expecting results, and jQuery will silently eat that error, requiring a bunch of inline error handling in the 'interesting' paths in your code. I'd be much happier with an optional parameter for silent failure or even writing the occasional try/catch.
I really don't get this discourse, jQuery API is much more ergonomic, concise and clearer than the DOM api. Sure you can do it but that doesn't mean you should
I think it's a bit of both. jQuery served the purpose of making web development more sane back in the day by handling all browser quirks. Part of that was the nice syntax.
I personally have tried to drop jQuery, but truthfully, its syntax is just much easier to use. Nowadays, I use Cash https://github.com/fabiospampinato/cash to give me the nice syntax without the bloat. It strikes the perfect balance for me.
I think that the improved vanilla js is now "satisficing" for more people. Their threshold of ergonomic usability has been achieved and they stop looking:
alternatively, if you need to use anything other than `forEach` for working on the list, you can turn the NodeList into an array using the array spread syntax (equivalent to using Array.from) e.g.
I still use jQuery for frontend JavaScript when I can. It's so much more efficient than native JavaScript. I can't imagine anyone prefers to write document.getElementById('element').style.display = 'none' rather than $('#element').hide();
There are fewer and fewer people who know jquery, so while this might be convenient for you or me, this is just more cognitive overhead for programmers who don't know jquery. There are multiple ways to hide an element, and what does `hide()` do? Some future programmer will need to look this up, and every other jquery method they stumble across.
The main problem I have with jquery though is there's no convention for event binding, so there is literally no way to know if an element depends on a jquery event handler without grepping the js for every class, id, and data selector on the object. Even that doesn't always help.
This makes it almost impossible to remove jquery from a project without breaking it.
Alpine or stimulus do a much better job of filling the event handling holes that still exist vanilla js. Dom traversal/manipulation in vanilla js is good enough, even if it isn't 100% as good as jquery.
I have had such a positive and lovely experience with it. It's the reactivity I've always wanted; ie plays nicely with VanillaJS without imposing a complex build process.
I think it's not so bad if you organize things reasonably well and minimize "lemme just modify the DOM a wee bit here" hacks. jQuery was popular at a time when "cowboy programming" was very common, leading to a lot of really bad/difficult jQuery apps; but that wasn't strictly jQuery's fault, as such.
That said, front-end frameworks can of course be a better choice for many things, even if it's just because it provides this kind of organisation by default making it easier for the, ehm, less organized devs.
Though for that little work, I'd rather have a small local library that implements what I need over standard DOM & JS parts instead of the full weight of jQuery.
Unless of course I need to support legacy browsers, then jQ is a no-brainer - that crap is solved there and I don't want to have to deal with it myself.
And while jQ is large compared to my little home-grown set of wrappers, it is small compared to all the other stuff many pages draw in these days, so perhaps size isn't a great metric to criticise it on!
That has the same ergonomics as the jQuery selector, and is just a bit longer. I feel like with editors that autocomplete, it's not enough of a difference to warrant the extra dependency.
I think the vanilla JS is better actually, because I actually know what it's doing.
I've never used JQuery before and would have assumed calling .hide() on an element would set the CSS attribute "visibility: hidden" rather than "display: none"
I would say jQuery has a place in any codebase that's simple enough it has imperative statements like that. Past a certain not-too-high level of complexity you're much better off writing "if (condition) then <element> else null" in your view and "condition = false" in your update instead of even the short $('#element').hide();.
jQuery was great in its time and still has some places where it can be a good tool for the job, but it isn't used less now because people like writing the longer form of Javascript; it's used less now because for many projects people are using frontend frameworks that let you operate at a higher level altogether.
By "more efficient" it seems like you mean "less typing" because that is significantly less efficient in terms of downloaded code size and performance (the jQuery code calls the vanilla code.)
PS. $ is an alias for document.getElementById so you can just do $('my_id').style.display = 'none'.
These days it seems like you don't touch DOM yourself anymore because it's all about virtual DOM that is managed by the framework of choice, which is probably ReactJS.
I used to be a big proponent of jQuery especially in the heyday of shims and browser hacks, but in the last few years I find it often gets in the way of what I'm trying to do. Now that the native browser APIs are maturing and relatively consistent, having direct access to the objects and their properties is simply more predictable than having to second-guess a layer of abstraction that does the same job but differently.
I have to remember, what does jQuery's .hide do again? It doesn't just set display to none or visibility hidden. Give it a duration, and it will use the style attribute to manipulate the display, width, height, opacity, padding, margin, etc. Then it leaves some style properties behind. Ugh. Do I really want to do all that stuff? Do I really want to build my UI framework around jQuery so I can avoid annoying transition artefacts?
Not hating on jQuery. Just my own experience. I used to feel liberated when using it because browser APIs were so terrible but now I feel encumbered if it's included as a dependency on a project I'm forced to work with, because it does so much black box magic. If you avoid certain things and stick to what it does well then it's not bad, but then there's no point using it because what it does well is no longer a pain point in browser APIs.
For me the main thing it excelled at was DOM selection and manipulation. Native does that just as well now. The secondary benefit was animation, which these days native CSS can go a long way without excess verbosity, and if you really need a more feature rich animation library I've not come across any better than Greensock for getting the job done, even if it does have a paid tier, though I am sure there are dozens of other libraries equally suited for animation, the point is that is not jQuery's strength either.
Anyway circling back to what you were saying, efficiency-wise, for any complex animations jQuery isn't the best tool for the job. For DOM manipulation native can be just as easy with some sugar. It can do a lot of unexpected and hidden things most people aren't aware are happening, so many bugs and time wasted realising jQuery was messing with style attributes that break an otherwise well designed layout.
I would rather write a few characters more code or a couple of lines more to have direct control over what's actually happening. That seems more efficient to me.
Edit: Ok on reflection I guess I am against jQuery, but I don't hate it. Using it these days just feels like trying to figure out how to get it to do what I want to the underlying APIs, when I could more easily and predictably just be manipulating the APIs directly.
The extra verbosity of vanilla JS never really bothered me.
I currently work with B2B applications in a sensitive banking context, so any time I can feasibly remove a 3rd party dependency it's almost certainly getting removed.
The extra LOC and time overhead is more than worth it for us. We get dinged on older products which do use jquery all the time by our customers who insist on using other 3rd party security scareware to light up random parts of their infra. I can't use 'but its elegant' or other technical handwavey bullshit as an excuse when the Chief Security Officer of Bank of America shoots me an email, even if there is zero chance the detected "vulnerability" would actually pose any risk in that particular context of use. Certainly, we could spend the time & energy fighting for exceptions, but its way easier to write a few extra lines of JS.
Don't forget the performance angle either. If you are doing a lot of element selection in a hot loop, document.getElementById can be orders of magnitude faster than the jQuery alternatives.
Everyone here seems to be talking about how great jQuery was for DOM interaction and that's true. But the other thing that was life changing about it was how easy it was to make ajax requests!
But the other thing that was life changing about it was how easy it was to make ajax requests!
What's the "modern" alternative to jQuery in that regard? I don't do much JS development, but if I needed to make an AJAX request today, my first instinct would probably still be to use jQuery.
Unless this team perfectly did a 1:1 replacement of jQuery calls with equivalent native JS functions, this isn't "removing a 30KB dependency reduced blocking time by 11%."
It's "we rewrote our JS and it reduced blocking time"
Talking to developers sometimes feels like hitting the same wall when I talk to people about whether putting all of your money into a house is a sound investment strategy.
There's a lot of willful blindness about cost structures. If it were just one or two people you might conclude that folks are trying to sweep things under the rug, and when I was just starting out I did feel that way. But it's so consistent that I often end up bonding with people who don't feel that way, without putting Dunbar's Number into any sort of danger.
One of the hardest "Code smell" issues I've had to contend with is the habit of people to spread out problems so thin that you can no longer see them, because they're everywhere. Like being in a room with a bad smell, eventually you can't detect it without a major change of perspective. Even though everyone new who comes in starts with, "what is that smell?"
11% of your blocking time on a library could be a perfectly reasonable *budget*. The mistake is not having a goal, or assuming the goal is zero. Zero is dumb, because if that's your target then we'd be talking a static HTML page and then why are they paying you? So what's your real budget? And given that budget, what's a reasonable proportion for different concerns? 1/9th spent on a library is probably a bargain.
Stuck out to me too, but the article is wrong, they didn't "reduce blocking time" by 11%, they reduced how long it takes to complete "JS Long Tasks" by 11% (63ms).
They do claim a "reduction in JS size" on all JS apps "between 31% and 49%."
For basic interaction, you don't need anything but vanilla JS. Browsers have come a long way since the days where jQuery was almost necessary to deal with all of the minor differences/bugs in various browsers.
I'll admit I'm a bit out of practice with the state of vanilla JS, but it seems like you'll be re-inventing the wheel for simple stuff.
Like a collapsible section that's lightly animated.
I worry too about people not considering accessibility.
A lot of my bugs day to day is not being able to tab into things like hover menus or being able to activate buttons because someone forgot to consider correct event callbacks.
Maybe it's different now, but using a jQuery makes it more likely the code will cover cases like that.
>> Eh. Everyone hates on jQuery, but for most informational sites that's really all you need for basic interaction.
The point seems to be that you don't even need that any more, so just get rid of it. Not sure why people latch onto cruft so much and defend its continued use.
On the performance side they cite 10 percent improvement, which doesn't sound like much to a lot of people. But remember that performance gains/regressions get compounded. Maybe there are 8 things that each eat 10 percent - you either start improving somewhere or you just refuse to even try. If I could improve 10 percent while removing a dependency I'd be all over that.
> Not sure why people latch onto cruft so much and defend its continued use.
A characteristic of communities with lots of people that do not have a theoretical background. JS, PHP, jQuery, some parts of Ruby/Python -- they defend it with their life, and I argue it's because the rest of the world looks very scary to them.
If you just want “basic interaction” without any framework complexity, alpine.js is way better than jquery. It’s extremely simple and does the basic data binding stuff that jquery lacks.
Readit News
One story he told a couple of times was about some grey beard who was before his time. The grey beard was once a legend in the company, often helicoptered into projects at the last minute to help them squeeze out the last bit of performance. His secret was he had a mental library of assembly language tricks applicable to the hardware of his day. But every few years his tricks were less and less relevant as hardware changed and compilers advanced. One day the grey beard was helicoptered into my leads project and everyone expected him to get them some gains. However, this was new hardware and none of his old tricks worked.
I think of this story whenever I see jQuery popup on Hacker News. There is always a strong contingent of devs who swear by this library. But to me, they are like the old grey beard who didn't update his knowledge as the times changed. At one time jQuery allowed them to be the hero and "Get Things Done" faster than their competition. But times have changed.
Argue with me if you must but take stories like this one for what they are worth. The writing is on the wall for jQuery. I was writing websites before jQuery existed, during the reign of jQuery and still today. If some candidate mentioned proficiency with jQuery during an interview I would be polite but internally I would note that the person might be out of touch. Not a red flag, but a yellow flag that I would follow up on. Nothing worse than bringing on a guy who claims to be senior/experienced and it turn out his old tricks won't work because they are no longer appropriate.
Maybe it's just me but with all the rampant age discrimination nowadays in tech, I really don't like to see the continued propagation of this stereotype.
All sorts of people of all ages are unwilling or unable to update their knowledge of new tech, there is no reason to link this characteristic to someones advanced age.
I can see how my choice of wording created an implication that people who have grey beards are old and that it is this oldness that contributes to their unwillingness to learn. The familiar cliche of "you can't teach an old dog new tricks".
What I actually hope to communicate is that there is a hubris which leads some to believe their skills do not require updating. The caution is that sooner or later this hubris may lead to sudden downfall. People may call on you in their time of need and you will fail. And this failure is not because of your age, your intelligence or your willingness to work hard. You will fail because you became overly comfortable with a passed status quo and you let your skills get out of date.
I see a trend of well-written, evidence backed articles where large, well funded sites are making a case to deprecate jQuery. These fact-based investigations into problems faced by their dev team result in a reasoned decision to remove a dependency that no longer justifies its cost. I encourage everyone to introspect if their defense of jQuery is on an equal technical footing to these types of investigations.
But you kind of do have to be old in order to have outdated knowledge: nobody young is going to learn assembly tricks which worked on MIPS and other past architectures. Older devs and companies not constantly learning new things and updating to best practices is a real phenomenon.
On the other hand, anecdotally most older developers actually do keep up to date with the latest best practices. And there are lots of decades-old frameworks which aren’t obsolete: lots of people greenfield projects with C++ and Spring Boot and .NET, and unless I’m mistaken the C ABI and system calls haven’t changed much over the past ~40 years. So it's not like being old automatically means or even really suggests you're going to use worse, outdated techniques.
What I have seen is awkward situations where you have two developers of roughly equal competence. One happens to be 45 and the other 28. Fine, nobody would care about that. Except that due to automatic annual raises, job switches, seniority bumps etc, the 45 year old developer is paid twice as much as the junior.
The rational response to this would be to say to align the two salaries (probably somewhere in the middle), but obviously the older one is never going to accept that - we all expect our salaries to "ratchet" upwards. So we end up with the irrational response, which is to sideline/kick-out the old expensive developer
> Maybe it's just me but with all the rampant age discrimination nowadays in tech, I really don't like to see the continued propagation of this stereotype.
I would agree. If you last a long time in tech, you're more than the sum of the libraries you've learned.
In 1998 I was in a web development class with a guy, and one time I went by his house and he showed me his little resume site he was working on. It was really nice looking, he had a great sense of design, I could have made it but I couldn't have designed it. But it was all table based, so I showed him CSS and extolled its virtues.
After which he exclaimed furiously "That's the problem with this industry, there's always new things to learn!"
He was just starting out and was already unwilling to update his knowledge of new tech!
I think he's working as a SiteCore admin in Dental association now. I'm pretty sure he has a nice work life balance, so make of that what you will.
> old trick's won't work
> writing is on the wall
jQuery still works and is used in an crazy amount of websites. It's not going away soon. The biggest downside is the extra network request, but it's probably cached in 99% of browsers, so all that's left is some extra CPU time.
You're also exaggerating the claims of jQuery defenders. No one here is arguing that the site should keep jQuery, or that you should write a ton of new jQuery code.
https://gist.github.com/pseudosavant/b86eedd9960ade958d49447...
One line more. But you have one dependency less, which is quite beneficial
These threads are completely ridiculous.
Whenever I want to use "vanilla JS" I use jQuery, because I find the DOM and various other JS APIs quite annoying to work with and jQuery makes things a lot smoother. There are some other, slightly smaller, libraries too, but they offer little advantages, are often unmaintained, and many people at least kind-of knows jQuery.
Bombastic absolute statements about "greybeards" being "out of touch" etc. is basically why I tend to avoid the JavaScript frontend community by the way, and also why I moved towards backend rather than frontend. I'm too old to deal with people who think there is One True Way™ to do things and that everyone who disagrees is a blubbering idiot (not that FE JS have a monopoly on this by any means, but it's far more common there).
However devs seeking employment should always be prepared to play up to what is trending vs what is appropriate.
But I agree I would not use jQuery in new project and when possible I would replace jQuery in existing code too.
This is still an ecosystem without a standard library and with no consistent design style/layout. It is janky and bad. It being "less bad than it used to be" isn't the shiny endorsement that everyone thinks it is.
This has worked for many years. I typically add a shorthand $ for the QSA part and on projects where I used to support IE11 you could add Array.from there but I haven’t bothered since IE was deprecated. jQuery does more but some of those things had performance impacts which were worth thinking about and the combo of QSA and fetch took care about about 90% of my projects.
document.querySelectorAll("div").forEach(i => i.innerText = "test")
Deleted Comment
I said while yes that's true as a dev if I told you I needed you to implement a new payment provider for billing would you tightly and directly align with who we used or abstract it away via some wrapper so that if we ever had to change it wouldn't be difficult? Of course everyone builds abstractions so you aren't stuck with a single provider because it's crazy not to.
I see jQuery as that abstraction. At the end of the day each browser is an api implementer and while they've come so far, that doesn't mean the situation is stable and we'll never see implementation fracture again. It of course doesn't have to be jQuery but any direct implementation of JS seems to have that risk which is easily mitigated by wrapping the basic functionality. I don't know why you wouldn't choose to do it.
Modern browsers have apis that are about as convenient as jQuery's, are standard across browsers, consistent with the language, and guaranteed to outlive jQuery the library. Aside from dot-chaining in a monadic sort of way, jQuery offers no benefit to the developer, while costing about 30kB of javascript.
https://youmightnotneedjquery.com/ is a handy illustration of this.
Are we really betting on Microsoft, Google, and Apple not getting into a feature fight again?
It is just a tool in the belt for an engineer. Can you use jQuery in 2022 or later to solve really amazing problems that impact user experience? You sure can! Would you be better off to use a modern javascript variant and stuff like react instead? You also absolutely would.
So just because a tool is old doesn't mean it can't be used to solve real user problems. There are still banks and airlines that run COBOL, and as a user, do you really care that much? I'd take "knows $insert_older_less_hip_tech_here" as experience of having done something for awhile.
Now if I was asked to write a front end today, I'd have to sit down and properly learn react + typescript (because javascript is awful without sensible type checking), and that would add to the time to ship, but is the correct thing to do.
Over the past 15 years or so browser JavaScript engines, except at the extreme edges, are roughly comparable. Further, a lot of the features of jQuery have been adopted into standard JavaScript.
So, the reason of eschewing jQuery, even for small pages, is simply that you don’t need it. Vanilla JS (or typescript) + modern CSS have pretty much all the same capabilities without any of the bloat. Using it today would be a little like using a library made to back port java 8 features onto a java 5 JVM.
It really is enjoyable working w/ react+typescript. :)
The react part is just for when you need to build something that needs architecture.
Deleted Comment
Why?
On https://kubirds.com I use:
jQuery appear: https://plugins.jquery.com/appear/
jQuery fancybox: https://fancyapps.com/docs/ui/fancybox/
Do not put jQuery to the trash yet, it still have a long life ahead.
Even scrolling down, and through the website, I didn't really understand it, until you compared to Nagios, which I am familiar with. Hope you don't mind a little unsolicited feedback. The website does look super clean!
I would love to read a paragraph of your elevator pitch the moment I lay my eyes on the site though. Cheers.
You're talking past one another. He's speaking in the context of AAA games, and the equivalent of that in the webdev world is a highly interactive application.
A long time we had a really good engineer who can crack topcoder and coding challenges with ease. We had a problem where we had to collect all changes to the User models and send it to the marketing platform. It was initially implemented in Rails Active Record which took progressively more time to collect and sync changes. Rails was hot at the time and SQL was really frowned upon. A lot of developers to this day hate SQL. Then came a "grey beard" who simply rewrote the whole thing into a single complex query that let the database figure out the optimum way to find the exact same data. Total time went from over 10hrs to 10mins.
You see, new hot technology is always replaced by another newer hot technology, and after hotness wanes, projects often become a abandoned and unmaintained.
Extra this if the proposed hot new tech comes from Google. In this case person pushing it should not only be stopped, but also slapped hard, to help come back to senses.
jQuery is the new Cobol!
I’m not a “grey beard” but I’m currently doing a freelance project updating the UI on a Perl+jQuery site… As much as we would like to rewrite it from scratch it’s very unlikely to ever happen, it’s going to be maintained as is with small steps towards “modernisation” over time.
0: jQuery is used by between 15-40x more sites than React depending source:
https://www.similartech.com/compare/jquery-vs-react-js
https://w3techs.com/technologies/comparison/js-jquery,js-rea...
It's not COBOL until something replaces jQuery that is easier than jQuery.
I think your portrayal of well-seasoned engineers as the derogatory 'greybeard' with a 'bag of tricks' and a hero complex -- glosses over the fact that many of these men and women have real hands-on experience with a multitude of technologies spanning decades, and in my mind there's real value / leadership qualities associated with individuals companies can rely on to just "get things done" in a pinch.
The assembly tricks got obsoleted because they're not needed anymore - we simply don't program in that hardware anymore.
jQuery still works fine to this day. It's just that engineers don't like it anymore. The same will happen to React in a few years.
I wouldn't hire a jQuery developer for working in a cushy company with their millions and their React codebases - React knowledge is actually one of the things we test for (and, unexplainably, one of the few exceptions we'll allow to avoid knowing about algorithms and time complexity).
If I had to build something with my money on the line, I'd definitely pick the jQuery veteran.
Recently I helicoptered into a call with three developers trying to execute a database upgrade and it seemed to be hanging. I joined the moment when they wanted to interrupt it and try again for the third time.
Only thing I asked was, if something is locking the schema. Then I left to another meeting and I saw them exchanging statements to find locks and delete them in the chat. Turns out there were long running queries hanging that nobody seems to care about. To me it's hard to believe nobody has configured a query timeout on the database
It doesn't sound like grey beard knew what he was actually doing, but more relying on his years of experience and good fortune that has kept him with a job up until then.
I think the most diplomatic way of distinguishing the two types of programmers is just to ask why they like JQuery.
"Because it helps me ship faster" may be a bit out of touch.
"Because it's a required competency in working with some code bases" are probably the latter.
Can I ask you about your current webstack?
"Nobody goes to that restaurant anymore, it's too busy."
https://dictionary.cambridge.org/dictionary/english/veteran, https://www.oxfordlearnersdictionaries.com/definition/englis... both give its primary meaning as "a person who has had a lot of experience of a particular activity" or similar. Even Wikipedia gives the generic definition first, and clarifies the more specific case as "military veteran".
Jquery is also a library not unlike any other a la react, redux, observables etc.
Jquery was successful but now there are better more powerful tools.
Lots of jquery can now be done natively or with better tools.
Dead Comment
Dead Comment
While this is true, I can still code circles around frontend developers using vanilla JS.
The decline of jQuery is mostly due to the rise of webapp frameworks like React and Vue. But if you are tasked with adding like, a button to a static webpage, jQuery is still the king.
Only thing I always have to look up is how to make sure my script is executed once everything is done and not before and "ready()" is obviously easier than adding an event listener to "DOMContentLoaded". Yeah, had to look it up for the comment.
Partly. Frameworks like Angular/React/Vue are a necessary byproduct of building and maintaining large codebases. But the fall of jQuery was largely a result of a more standards approach in mainstream browsers (said another way: deprecation of IE and not needing to work at maintaining consistent behavior across browsers), as well as adding traditional jQuery-like features to vanilla JS.
There really isn't a big use-case for jQuery anymore, although I will remember it fondly.
My first use of jQuery was in the dark days was building UIs (with things like drag and drop, etc) that had to run on Internet Explorer and Netscape. We'd started with "vanilla" but were ending up with what was effectively two separate codebases. Moving over to jQuery let us eliminate a massive amount of duplicate code and dramatically increased our productivity.
I still wonder occasionally if there's a place for a library that works like a strict subset of jQuery, but with different error/empty set handling defaults. Especially with list comprehensions. I found that 9 times out of 10 if I run a selector I'm expecting results, and jQuery will silently eat that error, requiring a bunch of inline error handling in the 'interesting' paths in your code. I'd be much happier with an optional parameter for silent failure or even writing the occasional try/catch.
I personally have tried to drop jQuery, but truthfully, its syntax is just much easier to use. Nowadays, I use Cash https://github.com/fabiospampinato/cash to give me the nice syntax without the bloat. It strikes the perfect balance for me.
https://en.wikipedia.org/wiki/Satisficing
Deleted Comment
I use a module "dqs.js" for all my query needs. It contains only these two lines:
And use it like this:The main problem I have with jquery though is there's no convention for event binding, so there is literally no way to know if an element depends on a jquery event handler without grepping the js for every class, id, and data selector on the object. Even that doesn't always help. This makes it almost impossible to remove jquery from a project without breaking it.
Alpine or stimulus do a much better job of filling the event handling holes that still exist vanilla js. Dom traversal/manipulation in vanilla js is good enough, even if it isn't 100% as good as jquery.
I have had such a positive and lovely experience with it. It's the reactivity I've always wanted; ie plays nicely with VanillaJS without imposing a complex build process.
Jr devs have the tendency then to discard jquery because "is old" not because it isn't working anymore.
That said, front-end frameworks can of course be a better choice for many things, even if it's just because it provides this kind of organisation by default making it easier for the, ehm, less organized devs.
Unless of course I need to support legacy browsers, then jQ is a no-brainer - that crap is solved there and I don't want to have to deal with it myself.
And while jQ is large compared to my little home-grown set of wrappers, it is small compared to all the other stuff many pages draw in these days, so perhaps size isn't a great metric to criticise it on!
document.querySelector('#element').style.display = 'none'
That has the same ergonomics as the jQuery selector, and is just a bit longer. I feel like with editors that autocomplete, it's not enough of a difference to warrant the extra dependency.
I've never used JQuery before and would have assumed calling .hide() on an element would set the CSS attribute "visibility: hidden" rather than "display: none"
Nitpick: This crashes if #element doesn't exist, while the jQuery one does not. Also, the jQuery selector is a tiny bit more powerful (:even, :odd).
IMHO, jQuery is good for what it's built for - a nicer interface than vanilla - but the main use case is much less needed now that frameworks exist.
Deleted Comment
PS. $ is an alias for document.getElementById so you can just do $('my_id').style.display = 'none'.
But I still prefer vanilla or anything but jq
with vanilla, it would be just typing a bunch of extra properties.
const $ = document.querySelectorAll.bind(document)
Then later:
$('#element').whatever
I used to be a big proponent of jQuery especially in the heyday of shims and browser hacks, but in the last few years I find it often gets in the way of what I'm trying to do. Now that the native browser APIs are maturing and relatively consistent, having direct access to the objects and their properties is simply more predictable than having to second-guess a layer of abstraction that does the same job but differently.
I have to remember, what does jQuery's .hide do again? It doesn't just set display to none or visibility hidden. Give it a duration, and it will use the style attribute to manipulate the display, width, height, opacity, padding, margin, etc. Then it leaves some style properties behind. Ugh. Do I really want to do all that stuff? Do I really want to build my UI framework around jQuery so I can avoid annoying transition artefacts?
Not hating on jQuery. Just my own experience. I used to feel liberated when using it because browser APIs were so terrible but now I feel encumbered if it's included as a dependency on a project I'm forced to work with, because it does so much black box magic. If you avoid certain things and stick to what it does well then it's not bad, but then there's no point using it because what it does well is no longer a pain point in browser APIs.
For me the main thing it excelled at was DOM selection and manipulation. Native does that just as well now. The secondary benefit was animation, which these days native CSS can go a long way without excess verbosity, and if you really need a more feature rich animation library I've not come across any better than Greensock for getting the job done, even if it does have a paid tier, though I am sure there are dozens of other libraries equally suited for animation, the point is that is not jQuery's strength either.
Anyway circling back to what you were saying, efficiency-wise, for any complex animations jQuery isn't the best tool for the job. For DOM manipulation native can be just as easy with some sugar. It can do a lot of unexpected and hidden things most people aren't aware are happening, so many bugs and time wasted realising jQuery was messing with style attributes that break an otherwise well designed layout.
I would rather write a few characters more code or a couple of lines more to have direct control over what's actually happening. That seems more efficient to me.
Edit: Ok on reflection I guess I am against jQuery, but I don't hate it. Using it these days just feels like trying to figure out how to get it to do what I want to the underlying APIs, when I could more easily and predictably just be manipulating the APIs directly.
I currently work with B2B applications in a sensitive banking context, so any time I can feasibly remove a 3rd party dependency it's almost certainly getting removed.
The extra LOC and time overhead is more than worth it for us. We get dinged on older products which do use jquery all the time by our customers who insist on using other 3rd party security scareware to light up random parts of their infra. I can't use 'but its elegant' or other technical handwavey bullshit as an excuse when the Chief Security Officer of Bank of America shoots me an email, even if there is zero chance the detected "vulnerability" would actually pose any risk in that particular context of use. Certainly, we could spend the time & energy fighting for exceptions, but its way easier to write a few extra lines of JS.
Don't forget the performance angle either. If you are doing a lot of element selection in a hot loop, document.getElementById can be orders of magnitude faster than the jQuery alternatives.
What's the "modern" alternative to jQuery in that regard? I don't do much JS development, but if I needed to make an AJAX request today, my first instinct would probably still be to use jQuery.
Deleted Comment
Unless this team perfectly did a 1:1 replacement of jQuery calls with equivalent native JS functions, this isn't "removing a 30KB dependency reduced blocking time by 11%."
It's "we rewrote our JS and it reduced blocking time"
There's a lot of willful blindness about cost structures. If it were just one or two people you might conclude that folks are trying to sweep things under the rug, and when I was just starting out I did feel that way. But it's so consistent that I often end up bonding with people who don't feel that way, without putting Dunbar's Number into any sort of danger.
One of the hardest "Code smell" issues I've had to contend with is the habit of people to spread out problems so thin that you can no longer see them, because they're everywhere. Like being in a room with a bad smell, eventually you can't detect it without a major change of perspective. Even though everyone new who comes in starts with, "what is that smell?"
11% of your blocking time on a library could be a perfectly reasonable *budget*. The mistake is not having a goal, or assuming the goal is zero. Zero is dumb, because if that's your target then we'd be talking a static HTML page and then why are they paying you? So what's your real budget? And given that budget, what's a reasonable proportion for different concerns? 1/9th spent on a library is probably a bargain.
They do claim a "reduction in JS size" on all JS apps "between 31% and 49%."
Speed really isn't bad, and it's so straightforward that it's hard to mis-use at this point.
I seem to have way more issues with newer frameworks/SPA if I'm not using chrome with no extensions.
Makes me nervous dealing with important stuff like banking or government sites.
Like a collapsible section that's lightly animated.
I worry too about people not considering accessibility.
A lot of my bugs day to day is not being able to tab into things like hover menus or being able to activate buttons because someone forgot to consider correct event callbacks.
Maybe it's different now, but using a jQuery makes it more likely the code will cover cases like that.
Vanilla js for similar things just looks like someone has waved the ugly stick at it.
There are sound arguments against jQuery but the "you can just use vanilla" is the least convincing.
It provides a clean API for manipulating the DOM, as this site demonstrates (which is ironic): https://youmightnotneedjquery.com/
Personally, for simple sites, I aim for vanilla JS but use jQuery (cash, actually) where it makes sense - such as working on collections of elements.
Deleted Comment
Steve Gibson's site is an example:
https://www.grc.com/default.htm
The point seems to be that you don't even need that any more, so just get rid of it. Not sure why people latch onto cruft so much and defend its continued use.
On the performance side they cite 10 percent improvement, which doesn't sound like much to a lot of people. But remember that performance gains/regressions get compounded. Maybe there are 8 things that each eat 10 percent - you either start improving somewhere or you just refuse to even try. If I could improve 10 percent while removing a dependency I'd be all over that.
A characteristic of communities with lots of people that do not have a theoretical background. JS, PHP, jQuery, some parts of Ruby/Python -- they defend it with their life, and I argue it's because the rest of the world looks very scary to them.
I think a lot of people owe a lot of thanks to jquery.
But in 2022 vanilla javascript is all you really need.
Deleted Comment