[reggieband]

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.

[dlandis]

> 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.

[reggieband]

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.

[lhorie]

IMHO this analogy doesn't really click, on multiple levels. Any old timer who uses jQuery surely is also aware of querySelectorAll and friends. There's even an entire website dedicated to catering to exactly that transition[0]. I don't think anyone defending jQuery is doing so out of a sense of hubris towards outdated knowledge, but rather because it ironically is more lightweight than a lot of the modern SPA craze, while still being more ergonomic than vanilla JS.

To try to shoehorn this back into the compiler analogy, modern frameworks would be like the advanced, complex and opaque compiler, and the grey beard is the guy that understands how stuff like HTML streaming and font download prioritization and hidden classes affect performance, whereas the team lead is analogous to the run-of-the-mill bootcamp grad that knows how to use the framework-du-jour but is way out of their depth if venturing outside the comfort of the framework and into the depths of those advanced topics.

And I think the gov.uk use case here might actually be an outlier in the sense that it actually considers performance of an already tight codebase, whereas a lot of jQuery deprecation efforts bring with them heavier alternatives in the name of maintainability or developer productivity or hiring or whatever. To be clear, many of these concerns are quite valid, but it seems a bit disingenuous to create a false dichotomy between understanding of low level concerns vs concerns about SDLC management. They aren't mutually exclusive.

[0] https://youmightnotneedjquery.com/

[adrusi]

I think you're trying to draw too much of an analogy here. The point is just that advertising jQuery expertise on your resume today is evidence (though not especially strong evidence) that you might be someone whose skills are of diminishing relevance. Myself, I'm not convinced there's much harm in using jQuery, it's not exactly heavyweight. But if in fact fewer and fewer pages include it, then your expertise is relevant on fewer and fewer pages. It doesn't make sense to add a dependency on jQuery to satisfy a single dev's preference.

If your expertise is in low-level browser performance but you lack deep knowledge of React/etc, your skills aren't of diminishing relevance, and probably won't be for a long time.

[lhorie]

IME, people list jQuery in their resumes all the time, typically as part of some previous job many eons ago. But I have read hundreds of resumes and just don't see people advertising jQuery as a primary skillset anymore, so to me suggesting that people still do this sounds very close to a strawman.

Something like Angular.js is a more apt example of a skill people still do advertise as a primary thing in their resumes these days and it most definitely plays into the diminishing relevance thing. On the other side of the spectrum, you have newbies writing down "HTML/CSS/Javascript" in their resume, which basically screams zero experience (aka "low/no relevance until they learn to speak the cool framework lingo"). There are plenty of other quote and quote "uncool" skills in actual resumes. Flux. Sagas. Ember. Etc.

So, yes, an argument can certainly be made that recruiters/interviewers do "discriminate" against various stereotypes to various degrees, and it isn't necessarily always based on ageism. A recruiter that reached out to me recently had an interesting term to describe this phenomenon: "skill commoditization", aka looking at people as snapshots in time, and evaluating some skillsets to be intrinsically worth less than others, even if they have some amount of overlap, instead of looking at people as malleable entities. It's worth thinking about how treating developers as commodities might hurt your hiring, especially if your hiring revolves heavily around evaluating for expertise in a specific framework.

[lnxg33k1]

I am not sure that the story has anything to do with the situation of jQuery today, because as I can see in your story there was a guy whose skills were of diminishing relevance, but surrounded by people whose skills in that area were never a thing in the first place, what I can draw from your story is that it's useless to cultivate an expertise in a niche field because it will be irrelevant in a few years?

[nonethewiser]

I don't think you're really listening

[_HMCB_]

Thank you. That needed said.

[narag]

I'm curious: what's replaced Query? I guess it's not a single library, but a set of frameworks...

[zelphirkalt]

Plain JavaScript replaced it. jQuery provided useful things at its time, indeed, but JS has been somewhat improved at least and learned the tricks, even improved upon them. JS is still somewhat ugly, but I will give it at least that much. Now one does not really need jQuery any longer for most things, which were done with it. I personally find plain JS API and fetch to be cleaner than jQuery stuff even. People still use jQuery it out of habbit or, because it would be a lot of work to get rid of it everywhere.

[petre]

Fetch is fine but I'm not going to write document.querySelector every time I have to select some nodes, which happens quite often.

[julianlam]

That's fine, pretty sure browsers alias $ and $$ to querySelector and querySelectorAll already (although I could be very wrong)

But speaking as someone who writes vanilla by default, it really really isn't as big an issue as you think it is.

[niccl]

upvoted because this is a really good example of how to respond to criticism

[kordlessagain]

> 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.

This is a strawman argument. It's a biased view you hold. Because of that, you make up a story to match your biases around people who use such-and-such library don't think they need to update their skill set. I'm not angry about this, but am only pointing out biased arguments create dissonance.

> 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.

You read something somewhere about how jQuery is a costly dependency. Yet, there are no links that I can see anywhere in the threads here, nor a good rational argument for people to NOT use jQuery because it is a costly dependency. There are opposing opinions on this, but the opinions that it needs to be included via CDN don't address the fact it can be hosted locally and the opinions "who needs all that code to load?" don't take into account that browsers and networks are bonkers fast nowadays. Who cares if it's a bit more code? It's not like jQuery is growing its codebase at the rate compute and network speed increases.

For that matter, could not the same argument be made of JavaScript itself? I taught myself Promises, not because I could stay "relevant", but because it makes good sense to write code that is easy to read and maintain, even if it is me doing both on my project. The code I produced when I wasn't doing Promises was "legacy" the second it hit the repo, and will be "costly" if someone else has to jump in and work on it to convert it to Promises, because they'll have to brain dump what I was thinking (or not) when I wrote it!

This salt and pepper beard stays up on technology. I didn't really write code in the past, but now I'm great at what I do and I fully intend on exploring new technologies when they compliment what I can do rapidly in the frameworks and methods I well understand, if that's what it takes to get to market faster.

[girvo]

> Who cares if it's a bit more code

Well, Gov.uk for one, as per the article you're commenting on. As they pointed out:

> Not everyone is tapping away on their 2022 MacBook Pro on a rip-roarin' broadband connection. GOV.UK has to be accessible to everyone, and that means keepin' it lean.

> Here's a few of the greatest hits from Matt Hobbs on what GOV.UK noticed in removing jQuery:

> - Less front end processing time overall.

> - 11% less blocking time at the 75th percentile.

> - 10% less blocking time for users at the 95th percentile. These are users who experience seriously adverse network and device conditions, and every performance gain matters especially for them.

[adhesive_wombat]

Yes, but that's a government site that's got an explicitly universal audience and is also pretty lightweight already.

If you're making a game, say, you may (may!) not care if Edna can't load it on a 1993 iMac, and you might be loading 40MB of resources, so another 24kB is not your pressing problem.

Engineering effort is always in short supply, and it is very expensive. Use it wisely. Sweeping judgements gleaned from very different products may not apply to your case.

[kordlessagain]

I can promise you Edna's 1993 Mac is dead and she has an iPad now.

[kordlessagain]

At what point did it cease to matter, though? Can anyone provide information on how many computers, world-wide if that's what we're shooting for, pre-date the mid 2010s? Because, after that, all those computers are plenty fast. Again, this particular library isn't growing much in computational demand. As for the bandwidth, let's assume the worst case is 128Kbps. jquery 3.6.0.min is 88KB. That's about a 6 second download. Then it's cached usually. Sure, there will be people on slower connections, but how many? Maybe Gov needs to do that no matter what, but that's not an excuse for other use cases.

[cxr]

jQuery is not the natural state of the world[1]; it's the use of jQuery that needs to be justified—not the decision not to use it...

1. https://news.ycombinator.com/item?id=29276656

[resonious]

> > 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.

> This is a strawman argument.

I'm not sure I follow. It reads to me like the original commenter is arguing that jQuery supporters have out-of-date knowledge. What's the strawman? jQuery supporters?

[kordlessagain]

Yes. Strawmen don't have anything to do with the thing being judged. The supporters are not necessarily grey beards who don't update their knowledge as the times changed. Also, other uses of biases exist in the text:

> his knowledge

Women are programmers too, and there are older ones out there maybe shaking their head at this type of judgement.

[armchairhacker]

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.

[giobox]

> But you kind of do have to be old in order to have outdated knowledge

I'm not so sure. Google and StackOverflow are chock full of outdated (sometimes dangerous!) advice and knowledge on just about any tech subject, which hurts the young as much as the old.

I've seen just as many outdated suggestions from junior devs repeating the first thing they found on google as I have older devs with stale knowledge. I'd probably argue the former has been a larger problem, honestly.

[threatofrain]

Bootcamps such as Hack Reactor (purchased by Galvanize) have curriculum which is basically outdated by 10 years, so you're going to have graduates using var, anonymous self-executing functions as modules that mutate the global scope, and libraries like jQuery and bluebird.

If any student leaves that program with a modern perspective of web dev (such as using Redux or even RTK), it will be due to their own personal grit.

C'est la vie.

[fallingknife]

Can't speak for Hack Reactor, but your generalization of "bootcamps like" is wrong. Went to a bootcamp in 2016 and was doing React/Redux on the front end.

[threatofrain]

> Bootcamps such as Hack Reactor (purchased by Galvanize)

No, this generalization is quite correct. If you went to a bootcamp which was not such as Hack Reactor, then perhaps you may wish to promote the program by name and discuss your experience there.

[CryptoBanker]

I went to Fullstack Academy in 2017 and React and Redux were both part of the core curriculum

[seattle_spring]

This is totally wrong. I hired a couple devs from Hack Reactor years ago and they had tons of lessons based on React and the ecosystem around it.

[threatofrain]

Your information might not reflect the online-only program, which is now the only choice. My information is from two sequential cohorts of students who are yet to graduate. Also, if you know what to Google for, then you can see how the curriculum has updated over time. Some students do this to cheat, and they can do so precisely because the curriculum is largely frozen in time.

Hack Reactor has made Redux completely optional and so almost nobody choose it for their projects. This may have been in response to transitioning to an online-only program. If students understand anything on the "React ecosystem" including even Redux, it is due to their own personal ambition. If you see Redux explicitly listed in their curriculum, do not be confused.

If you see students with Next.js, RTK, or any other framework or library from the React ecosystem on their portfolio, that is due to their own grit.

[eyko]

I'm nearing 40 and I've seen a bit of both. By far the best teams I've worked in had a healthy mixture of experienced developers and younger ones, although I'd say the main catalyst was a mentoring mentality where everyone, young and old, was encouraged to share their experiences (especially the bad ones) in an attempt to brainstorm/crowdsource an improvement to the status quo.

I've also seen the opposite of what you'd expect: a young startup with a very young team that functioned on outdated practices and tools. My first contact with their codebase was a shock to the system – a mishmash of competing coding styles and conventions, barely any of them a best practice, much of it not very idiomatic, an alarming lack of consistency. The choice of tools, libraries and frameworks was (by startup standards) definitely not best in class, and where good choices had been made, the joy was short lived by realisation that they were on old versions, or not using their tooling properly.

But, anecdotes aside, there's a point that generally gets overlooked. Best practices and good developer experience are the result of intentional choices, often in retrospect. The only way to come up with best practices or to improve DX is through experience -- especially poor experiences. I mean, who would've thought that experience was an asset.

[JKCalhoun]

I'm an old software dev.

To be sure, when I began a good dev was good at memory management (ha, ha).

More recently, a good dev is one that is good at concurrency.

New devs might not understand memory management, should they though? Has everyone come across (at least once) where a junior dev creating an "integer object"? Or perhaps an object to represent a character?

When I began I rarely even saw a single secondary thread in code, very rarely saw the need to create one. Then again, one core machines so.

[markdown]

> but you kind of do have to be old in order to have outdated knowledge.

Not in the frontend dev space. I once left it for 2 years. when i came back it was a whole new world

[jasonfarnon]

anecdotally most older developers actually do keep up to date with the latest best practices.

As an old guy I would find it very hard to keep up to date with the "latest best practices" because I tend to think of "latest" and "best practices" as antithetical. JQuery is a good example: I never invested time in it since I figured it would pass. I could smell it from the way kids were raving about it. So this type of article foreshadowing its demise is nice to see. Like when you drag your feet on some looming deadline at work and some force majeure makes it completely irrelevant.

[drdec]

IMHO there was definitely a period when jQuery solved a whole host of problems for you and allowed you to write client side code much faster. If you weren't using jQuery or an equivalent you were kneecapping yourself unnecessarily.

[JKCalhoun]

I sat out of jQuery as well but more because I dislike (distrust?) layers, prefer to be closer to the stack as it were.

Either that's wisdom from an older dev that has been burned in the past or that's just an old dev set in his ways. Take your pick. ;-)

[namdnay]

Do you see a lot of age discrimination it tech?

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

[Barrin92]

>Do you see a lot of age discrimination it tech?

Yep, especially culturally rather than financially. Almost everywhere I've worked there was the implicit assumption that engineers graduate out of coding jobs into management roles. In a lot of places there's the idea that focusing on writing software is some sort of career dead-end for older people which is a shame for anyone who just likes coding. I think it's widely perceived as a young person's job for no good reason.

And on the business side it's also pretty blatant. IIRC founders in their 40s are statistically most successful. Yet prominent people in the industry still openly fetishize youth.

[prohobo]

Really? I see 40+ people as diversity hires for the most part. They're there so no one can say the company is ageist. The "good" devs become managers or magically disappear. Magically as in they get banished to some other realm I've never been able to see.

That, to me, says there's plenty of ageism.

If it was as simple as "they ask for too much", then someone would snap them out of it and we'd see plenty of older devs at software companies. Maybe less than younger devs, but plenty anyway.

Honestly, I'd prefer if there were more older engineers to show the younger ones how dumb they are. Maybe better at building dynamic frontends, but dumber. That kind of seniority is sorely missing in software engineering, and it would drive standards upwards rather than downwards as they currently are.

I'm currently in between, and wish I had more mentorship.

[namdnay]

> The "good" devs become managers or magically disappear. Magically as in they get banished to some other realm I've never been able to see.

I agree with you here - the question is why? I don't think it's because we're discriminated against for being old, I think it's because in 99% of cases (we can't all be donald knuth), our cost grows faster than our skills. So we either move to management/business (where experience matters more and it's much harder to quantify productivity), or we become "the overpaid one".

> If it was as simple as "they ask for too much", then someone would snap them out of it and we'd see plenty of older devs at software companies

But they wouldn't snap out of it. (a) in most countries you can't demote people, (b) it's very hard psychologically to accept being paid less for the same job

> more older engineers to show the younger ones how dumb they are.

I'm talking about 45+ vs 30 years olds here, not 30 vs 23.

[cma]

I think the dominant effect is because the whole field is rapidly growing, so newly trained and younger is a disproportionately high amount relative to if it was at a steady state.

[bcrosby95]

I don't know if we're just exceptionally lucky, but my friend group - the vast majority of which are still doing coding/sysadmin/devopsy stuff - are in our 40s and we have all had no problem finding employment.

I think a major factor is that the field just exploded so much over the past 20 years. Statistically, people over 40 are going to be in the minority.

I also do think a lot of startups maybe aren't the best place for older people. My brain wastes a lot of cycles on edge cases I've learned to identify from experience, that don't matter if you just need to slop some shit out the door ASAP.

[mikepurvis]

I thought it connected well to the staff-vs-line article from the other day— that the later you are in your career, the more it makes sense to be in a "staff"-type role, since a staff person is likely to have a lot of autonomy, long term ownership, more access to senior management, less dependence on mentorship, etc.

Following from that, it's easy to imagine that a bunch of the older engineers that you don't see at software/tech companies have in fact graduated into extremely well-paid, long-term roles working on software for banks, insurers, utilities, resource companies, whatever.

[JKCalhoun]

I tried to mentor in the last few years of my career. The young'ns didn't seem to want to be mentored though.

[vkou]

If the 45-year old developer has been with the firm for 15 years, they may have roughly equal competence in writing code, but unless they spent the past decade with their eyes and ears closed, the 45-year old should have vastly more institutional knowledge.

Seniority bumps, x-weeks-vacation-after-y-years-of-service reward that intangible.

[lanstin]

Tho institutional knowledge can cut both ways - being indignant rather than resigned about the problems, and trying to fix things without knowing why all the prior attempts failed, and even being friendly to people that are politically outcast, are all great. Even just bringing novel solutions from outside industries or organizations to bear on problems is useful (tho experience is also a common cause for having a variety of solutions in ones tool box).

[judge2020]

It was just a reference to the person in the story, not an allusion to "because he was old he didn't try to update his knowledge/continue learning".

[squiffsquiff]

So why describe him as a "greybeard" then? It are you claiming to have met many younger and/or female 'greybeards'?

If your answer is that 'it's just part of the story'. Well that's precisely the complaint.

[capableweb]

The meaning of "greybeard" have moved from being literally, to current be figuratively. It doesn't mean that the person is A) old, B) man C) have a beard and D) that the beard is grey.

It simply means someone experienced/being at something for a long time. The greybeards at a company can be all women of the age 26, but if they been with the company for 5 years when the company got started 5 years ago, they are the greybeards of that company.

Might as well say "veteran" or "old-timer", although "old-timer" would imply actual old age, "veteran" implies nothing like that.

[avar]

"veteran", from latin "vetus" meaning "old" :)

[capableweb]

Weirdly enough, we don't speak latin no more, and the meaning of words changes over time :)

[skavi]

greybeard has always felt like a term of respect to me. personally i think of the type of person who could have been at bell labs in its heydays. definitely could exclude women though.

[jokethrowaway]

It's 2022. Men can get pregnant and women can have a beard.

Greybeards is an inclusive term and it's a well known term.

[justbaker]

I hope your username is accurate.

[jokethrowaway]

fighting fire with their own fire

[burnished]

Because it communicates a well understood idea. It is great that we as a society are becoming more conscious about the way we speak, but I feel like your complaints here are aimed anyone who isn't achieving the proper level of 'purity'.

[Suzuran]

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.

[edoloughlin]

>> 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.

[aledalgrande]

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.

[bryanrasmussen]

>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.

[Apofis]

The problem is that a lot of old school website devs can write jQuery and very very little actual JavaScript.

[nonethewiser]

But the guy in the story was old.

[o10449366]

The OP doesn't link the characteristic to their example's age.

[goodguyamerikan]

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

[adhesive_wombat]

Also you don't get good at assembly optimisation without understanding things like cache coherency and register allocations. New CPUs don't suddenly invalidate that ability to reason about what the problem might be and what might help (and what might not). Crucially, you already know how to adjust your existing skills to apply to new things.

[sunjester]

You have offended me.

[vlunkr]

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.

[somehnacct3757]

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.

[sefrost]

I believe Safari has been doing it since 2013.

https://bugs.webkit.org/show_bug.cgi?id=110269

[Gigachad]

Someone did tests on it before this and found that with how many versions and cdn sources there are, your exact jquery is almost never in the cache.

[underwater]

Really proves the point that knowledge will atrophy. As a dev you need to invest in evergreen skills as well as trivia.

[vlunkr]

Fair enough. But it is still cached for your site.

[lelandfe]

jQuery is not unique in being cacheable

[DeathArrow]

I rather not write 10 lines of Vanilla JS when I can write a line using jQuery. And I do prefer jQuery-style syntax for manipulating the DOM.

[pseudosavant]

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.

https://gist.github.com/pseudosavant/b86eedd9960ade958d49447...

[hu3]

This doesn't have closest(), next(), prev(), siblings() and a bunch of other DOM traversers.

[atoav]

As somwone who constantly replaces jquey with vanilla js the difference is more like two lines of jquery against 3 lines of vannila js.

One line more. But you have one dependency less, which is quite beneficial

[pseudosavant]

Update: fixed formatting

A lot of times the jQuery syntax is easier to understand (IMO).

Remove element exmample:

jQuery API:

  $('.element').remove()

DOM API:

  document.querySelector('.element').parentNode.removeChild(document.querySelector('.element'))

or if you want to introduce another variable just to remove the element:

  const child = document.querySelector('.element');
  child.parentNode.removeChild(child);

Create element example:

jQuery API:

  const fooElement = $('<div class="foo" style="display: none">')

DOM API:

  const fooElement = document.createElement('div');
  fooElement.classList.add('foo');
  fooElement.setAttribute('style', 'display: none');

I know which ones I'd rather write and read.

[egeozcan]

HTMLElement.prototype.remove exists everywhere except IE:

https://developer.mozilla.org/en-US/docs/Web/API/Element/rem...

Also for element creation:

Object.assign(document.createElement("div"), { class: "foo", style: "display:none" });

I mean, you normally abstract these things with a helper fn or two, without importing the whole jQuery anyway.

[wvenable]

> I mean, you normally abstract these things with a helper fn or two, without importing the whole jQuery anyway.

Add enough helper functions are you're at jQuery anyway. Looking at the jQuery source code, it manages a lot of edge cases that I don't really have time to figure out on my own.

The DOM API isn't really designed that well for human consumption.

https://developer.mozilla.org/en-US/docs/Web/API/Node/nodeTy...

[ratww]

> Add enough helper functions are you're at jQuery anyway.

I really hate these exaggerations. jQuery is, last I checked, over 200k unminified. Anyone writing enough helper functions to get to a fraction of that is already a pathological case.

[adhesive_wombat]

> Looking at the jQuery source code, it manages a lot of edge cases that I don't really have time to figure out on my own.

Reminds me of the warning about rewriting old "messy" codebases. I am paraphrasing, but the upshot was "You know what those weird and ugly bits of code are? They're bug fixes, and they were earned through sweat and blood and years over a period of many, many years."

[egeozcan]

You need to write a lot of helpers to come close to jQuery. Also edge cases aren't that big of a deal now that IE is near it's EOL.

[cogman10]

IE 11 hits it’s EOL next month. So, really probably not a whole lot of reason not to just pull the trigger and inform everyone that complains of this fact.

[mikojan]

Or you could just do document.querySelector('.element').remove()

[yakshaving_jgt]

JavaScript:

    var xs = document.querySelectorAll('.x');

    for (var i = 0; i < xs.length; i++) {
      xs[i].addEventListener('click', function() {
        this.style.display = 'none';
      });
    }

jQuery:

    $('.x').on('click', function() { $(this).hide() });

ಠ_ಠ

[recursive]

Also javascript

    document.body.addEventListener("click", ev => ev.target.classList.contains('x') && ev.target.hidden = true);

[jokethrowaway]

jQuery emerged from the market and it's pretty close to what developers wanted to express.

JS is design by a committee full of people afraid to come out as "not-as-kind" and completely detached from reality.

True, doing some of the things which were half an hour on stack overflow or 1 line of jQuery became a couple of lines of vanilla JS but the API is still pretty awful.

Think about XHR > fetch vs $.get or $.post

I agree, I'll try to use vanilla JS and google something when I need to ship some code - but for hacking around I'll just bring in jQuery and write 1-liners at blazing speed.

[smrtinsert]

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.

These threads are completely ridiculous.

[Beltalowda]

> 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).

[dagaci]

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.

[simion314]

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.

[Someone1234]

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.

[nikanj]

jQuery is implemented in vanilla JS, thus logically all of it’s features can be done vanilla JS

[0xFF0123]

That's a bit like saying everyone should code in assembly. The argument isn't whether it's possible, but whether it's easier / more efficient.

[nikanj]

I guess I should have added more meat to my comment:

It’s frustrating when people reject a good tool like jQuery, with the argument that the same functionality can be achieved with just vanilla JS.

[adamisom]

That is generally true and not really specific to jquery

[acdha]

> 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.

document.querySelectorAll("div").forEach(i => i.innerText = "test")

[megous]

You can extend HtmlElementCollection prototype with any methods you like. (it's NodeList, btw, what's returned from querySelectorAll)

[strbean]

My understanding is that mutating built in prototypes is very bad. Not just for interop reasons, but because doing so really hinders many optimizations javascript engines perform.

[cogman10]

Adding methods to prototypes is effectively free. The only time mutating a builtin prototype has negative consequences is when you replace a builtin function with your own thing. All javascript engines (that I'm aware of) JIT at the method level so there's not really a performance impact modifying a prototype.

[strbean]

Ah, I think this is what I was thinking of: https://developer.mozilla.org/en-US/docs/Web/JavaScript/The_...

It seems this only pertains specifically to overwriting the __proto__ of an existing object (the is the prototype of other things).

[simion314]

There is an issue you need to be aware , be careful if you hide the fact that this collection is "live". I mean this part from the docs

>An HTMLCollection in the HTML DOM is live; it is automatically updated when the underlying document is changed. For this reason it is a good idea to make a copy (eg. using Array.from) to iterate over if adding, moving, or removing nodes.

So you need something that will also be efficient and correct, not a 5 minutes implementation.

[megous]

Same issue applies if you mutate array you're iterating over during iteration using those Array.prototype functions. This is just a general issue with any data structure.

[robalfonso]

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.

[azangru]

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.

[parineum]

> guaranteed to outlive jQuery the library

There's absolutely no reason to believe that considering those APIs add new features independently of each other. A library like jQuery can serve as an intermediary if browser A implements new feature X that is possible in browser B but through excessive (and slow) DOM manipulation.

jQuery can act as a bridge between the time browser A's implementation and browser B's.

[MrJohz]

There's not much added to the browser that's particularly independent (i.e browser A adds it with browser B having no plan to implement it at all), and when there are APIs that are perhaps newer and not widespread yet, it's usually easier to pull in a specific polyfill (or ponyfill) for that specific feature, rather than rely on one library that's trying to cover everything. Especially as those libraries tend to mimic the API as it is expected to be standardised, rather than implementing a distinct API as jQuery does.

In practice, I'd much rather use the native APIs to do things in the browser than a wrapper library, because I find abstraction from these wrappers tends to get in the way as often as it helps. With modern JavaScript (for-of, the spread operator, far more array functions), it's usually only one or two lines more code to do things the native way, and I find it saves me a lot of complexity down the line.

[gkbrk]

> There's not much added to the browser that's particularly independent (i.e browser A adds it with browser B having no plan to implement it at all)

You haven't seen the privacy nightmare APIs Google is trying to push on web "standards"? The only other two browsers, Firefox and Safari, are not going to implement most of them in the foreseeable future.

[azangru]

> the privacy nightmare APIs

Unless something has changed about jQuery, it is only concerned with DOM manipulation and data fetching. Do any of the privacy nightmare apis touch those areas?

[lalaland1125]

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.

https://youmightnotneedjquery.com/ is a handy illustration of this.

[evilotto]

I fail to see how replacing 1 line of jQuery with 10 lines of plain js is simple. Sure, you don't use those 10 lines all over the place, you write a function ... but then aren't you just recreating jQuery?

[franciscop]

Yes, and if you continue long enough you end up with one of the many jQuery alternatives, like mine:

https://umbrellajs.com/

[shadofx]

Yes but only the parts you need, which means better performance and job security.

[jefftk]

That site was very helpful when it first came out, but now that most of us don't even need to support IE11 it's assumption that you at least want to support IE10 is very stale.

[Gare]

What? Web APIs are one of the most stable APIs in existence. "Don't break the web" is taken very seriously.

[damon_c]

The context for this belief has only existed for about 10 years now.

[plorkyeran]

The phrase "Don't break the web" is a bit newer, but it's basically the sentiment that lead to WHATWG forming 18 years ago, and one of the big defining goals of HTML5 was to set a foundation for expanding the web platform in a backwards-compatible way. HTML5 has been out for about as long as the invention of the web to HTML5.

[8ytecoder]

More like half of that. I did web development in 2012. We couldn't have done it without jQuery.

[anotheracctfo]

Yeah that's what I'm afraid of. IE 5.5 diverging from Netscape 4 again.

Are we really betting on Microsoft, Google, and Apple not getting into a feature fight again?

[dudus]

They do get into feature fights often. See Apple not adopting PWAs, or IE focusing on blocking 3rd party cookies. But the parts that are covered by jQuery are solved and agreed upon.

[SEJeff]

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.

[cogman10]

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.

[strbean]

> smooth over and fix differences between browser JavaScript engines

And let us avoid some of the extremely verbose and un-ergonomic standard APIs.

[tambourine_man]

Mootools, Prototype, all offered cross browser compatibility.

The reason we're not discussing them today is that jQuery has a stupendous API that simply hasn't been matched yet.

[justbaker]

> 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. :)

[tinco]

Why react though? Just modern JavaScript (and typescript) is a great replacement for jQuery.

The react part is just for when you need to build something that needs architecture.

[SEJeff]

I primarily did this out of anger and used https://datatables.net to build web based data apps. That’s a really mature and extensible table widget and it would be a shame to not use it as it’s been out years, but in general I know react is how many good modern web apps are written so I’d start there.

[tambourine_man]

>Would you be better off to use a modern javascript variant and stuff like react instead? You also absolutely would.

Why?

[SEJeff]

Because jQuery was written to paper over limitations in ancient browsers that no longer exist, and modern (es6+) vanilla js is actually quite good. One of the primary reasons jQuery was invented is not relevant today. It’s still good software, but I’d say the same about the Perl lwp library yet you don’t see people using it.

[tambourine_man]

Cross browser compatibility was just one of the reasons for jQuery's success. But lots of other competing libraries offered it too at the time. That was the bare minimum a library had to do.

The reason jQuery was so successful, is still so widely used and was instrumental in fomenting HTML5 and killing Flash was its API. Nothing has come close to it in terseness, elegance and power.

Just skim this thread for examples.

[linkdd]

what's so wrong about sprinkling some jquery on a static website (generated with hugo or jekyll)?

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.

[httpsterio]

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.

[influx]

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.

[linkdd]

Thank you a lot for the feedback! We'll definitely do something about it :)

[retcon]

It's only8 minutes since your responseso I'd just like to say that I almost immediately got the gist of your product before any changes. Long advertising experience means like a remedial English teacher I'm better than most reading poorer copy but I consider your(unchanged) copy very good. Unfortunately without the words"audit", "WORM" and"incident search" present or prominent I'm not your market. But I could think of many thousands of publication sites longing for your tool, if those terms applied.

[linkdd]

Thank you for the feedback as well :)

> I'm better than most reading poorer copy but I consider your(unchanged) copy very good.

This is nice to hear/read, yet I'm a perfectionist who knows perfection do not exist. The pitch can always be improved and clarity/transparency is very important to us.

> Unfortunately without the words"audit", "WORM" and"incident search" present or prominent I'm not your market.

This proves my previous point, since we rely on Docker images to implement the monitoring/reactivity part, literally ANY workflow/business logic can be applied (but we've been told that it's hard to trust "it can do everything").

> But I could think of many thousands of publication sites longing for your tool, if those terms applied.

I'd love to get in touch with you about that, if you have time, you can find my contact info in my profile: https://news.ycombinator.com/user?id=linkdd

[ianleeclark]

> 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.

[bcrosby95]

I don't see anyone saying to use jQuery for highly interactive applications. If that is the comparison, its not talking past eachother, the original comment is a strawman.

[ianleeclark]

> I don't see anyone saying to use jQuery for highly interactive applications.

I don't know what to tell you. The first sentence in my comment was a quote and the rest of the comment was responding to say how that quote was misunderstanding the OP.

I never said anyone specifically said to do that, but that, in the metaphor that the OP made, a static website isn't an accurate comparison to a AAA game.

[8ytecoder]

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.

[Andrew_nenakhov]

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.

[samwillis]

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:

https://www.similartech.com/compare/jquery-vs-react-js

https://w3techs.com/technologies/comparison/js-jquery,js-rea...

[dheera]

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.

[darepublic]

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

[0xCAP]

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.

[ConcernedCoder]

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.

[jokethrowaway]

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.

[de6u99er]

LOL

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

[dapids]

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.

[TOMDM]

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.

[Abishek_Muthian]

> I was writing websites before jQuery existed, during the reign of jQuery and still today

Can I ask you about your current webstack?

[smrtinsert]

Yeah this is why I fired my contractor for using a wrench. A hammer should be good enough.

[arbitrage]

jQuery is dead, Netcraft confirms it?

"Nobody goes to that restaurant anymore, it's too busy."

[soperj]

What newer libraries are you using for performance gains?

[planetsprite]

when you say veteran do u actually mean veteran of a real life combat war who later joined the games industry or veteran of the games industry

[Smaug123]

You know "veteran" does mean "someone with a lot of experience in something", right? In non-US countries that's even the primary meaning.

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".

[ThunderSizzle]

That doesn't answer the question. The ambiguity remains, and so does the question.

[bezospen15]

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

[bern4444]

I think the parent comment is referencing how much is built into JS natively today that people used to use jquery to do.

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.

[treeman79]

I’ve seen a single jQuery developer be replace by a team of 20 angular developers a couple times now. The jQuery was far more productive