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.
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.
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.
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.
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?
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.
I know. Most of its funtionality was superseeded by Js APIs which I already use (Promises vs Deferred, fetch vs. ajax). I might still need an alternative for building and editing query string parameters though. Plus most of the somewhat outdated libs in our project use it anyway.
> 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.
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.
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.
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.
> > 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?
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.
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.
> 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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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
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.
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.
> 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.
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.
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.
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.
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.
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).
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.
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.
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'.
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
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.
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.
> 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.
> 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.
Browsing the source of jQuery and I don't find it bloated but I find a lot of knowledge in there that a naive user the DOM API would most likely know about.
It's kind of like how you can comparing languages using simple example code isn't relevant because proper code with full error handling and edge case handling can be very different from a naive example.
The point is that this is a strawman. "Enough helper functions" to get to jQuery is 288580 bytes. A quarter of that, or even a tenth of that, is already a pathological case and way beyond almost every case of "jQuery substitution" that would happen in practice.
I could read and understand the entire jQuery source code in a single afternoon -- it's not that big. Even in the few minutes I spent reading it, I learned a few things I didn't know.
The worst thing about the web as a platform is the need to count bytes.
Once again, my friend, that's not the point, and I'm not even talking about it anywhere. I get it that you like jQuery, but your reply defending it has absolutely nothing to do with my reply.
Nobody is reimplementing the 280k of jQuery as part of their projects, so no, you won't be "at jQuery anyway". That's bullshit.
I don't like jQuery -- I mean I use it but it doesn't occupy enough brain space to even have a strong opinion on it either way. If I took jQuery out then I'd have to care more because would need to re-implement all the pieces of jQuery that my projects already use. Is that going to be 280k worth? No. Is going to be a couple of one-liners? No, because jQuery hides a lot of complexity under it's relatively simple API that take a lot of JavaScript to reproduce.
It's not crazy that to accomplish what jQuery accomplishes without jQuery you're going to need almost the same amount of code as jQuery. It's not re-implementing the DOM -- it's a pretty thin but broad wrapper. If you don't need something, remove it.
Alright, we seem to be talking past each other. Maybe that's the sign this is not a productive discussion.
I'm not calling jQuery is bloated or difficult to read, nor I am telling anyone they should count bytes.
> Is going to be a couple of one-liners? No, because jQuery hides a lot of complexity under it's relatively simple API that take a lot of JavaScript to reproduce.
> It's not crazy that to accomplish what jQuery accomplishes without jQuery you're going to need almost the same amount of code as jQuery
Once again, that's my whole point.
What I'm saying is that jQuery isn't a 100-line library. The whole of jQuery is not being trivially reimplemented at several places. Projects reimplementing portions of jQuery functionality (a la youmightnotneedjquery.com) are usually only reimplementing very very few things, and are leaving out lots of stuff. Different projects have different needs, some people don't need the whole library, some do, others don't care. That's it.
You might be right about the discussion. But I was thinking about this and I think my point comes down to the basic issue of almost every library or big piece of software. Nobody uses 100% of any big library. Nobody uses 100% of Microsoft Word. Most people use about 20%. But the problem is everyone uses a different 20% so libraries and software have a lot of features.
The argument against jQuery is thus an argument against libraries in general. Why include any dependency that you only use a small part of? You can always implement anything yourself.
The counting bytes comment is because the web, as a platform, is very size-conscious. Rarely does anyone complain about the size of libc and how, since they only use file functions, that should just call into the Linux kernel directly.
Would we even by having this discussion if you could just tree-shake out all the parts of jQuery that you never use at build time?
> The argument against jQuery is thus an argument against libraries in general.
Then it's a nice thing that I never made any argument against including jQuery or any library in a page or project, nor I'm saying anyone should reimplement it, or even do anything. I'm not talking about those things.
> Would we even by having this discussion
We aren't even having this discussion. Seems like you're having an argument against an imaginary version of me. I'm not saying (or implying) the things you are arguing against.
Your argument is that is that body is going to re-implement all of jQuery with their own helper functions. I got that. It's just not a very interesting point. Was I using hyperbole -- yes. You got me.
> 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."
I don't find the jQuery API to be particularly friendly. It tries to be cute and ends up being annoying. Its implementing code is also an abomination, so not particularly helpful. I'd rather read through Gecko internals than try to figure out what the hell a jQuery helper actually returns.
The DOM is at least very, very well documented. jQuery has documentation, but it's not even close. It gives away what jQuery always has been, which is a library that is aimed mainly at assisting bag-of-tricks StackOverflow programmers than people who actually want to understand their programs and the object graph they work on.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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?
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.
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?
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.
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.
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.
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. :)
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.
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.
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.
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.
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.
> 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.
> 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.
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.
> 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.
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.
Simplifying interaction with the DOM is obviously a huge feature of jQuery. But also the functions are just very nicely laid out with the assumption you are doing web stuff.
$(thing).doThis() is just so perfectly terse and understandable for what it's doing. Not just writing, I find jQuery to be very, very easy to understand and read.
>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 personally have tried to drop jQuery, but truthfully, its syntax is just much easier to use.
It's not just the syntax, it's also the expression-heavy and chained API which makes it much more flexible. As well as the set-oriented approach, which can lead to performance issues if you're not careful but is generally extremely enjoyable.
The DOM is an extremely procedural, plodding API, you need to name everything because you always need to set attributes and call non-chainable side-effecting APIs, not to mention the fecking NodeList which has to be converted to an array to do basically anything useful (in part because Javascript never really embraced iterators, and instead uses arrays for everything still).
I guess you could mitigate that with an "API adapter", but...
Although writing jQuery is still shorter (And likely will forever be).
Editor (like vscode) nowadays is much more smarter then the era.
A lot of API with long names is no longer a issue to type. You just mark the variable as a element. After that, autocomplete handles the rest for you. Shorten the gap with experience of using jQuery. If developer tools is still as dumb as that era. I would think the transition is impossible.
And there are also more frameworks to enhance experience of style modification or templating. Back to then, there are only some dumb template that do initial rendering. But framework these days also handles update for you. So you don't really need to modify it directly by yourself unless in some edge case.
I did a javascript project targeting web/blackberry and early ios. We used jQuery to smooth out the kinks (or that's what our lead told us). It worked as expected.
Went from disliking it to really liking the syntax. Its pretty clear and easy to use, which is why I still use it. We don't use it extensively becaue we're still on the "submit form, get page back with javascript graph and data tables table, development model. We probably should transition to a framework, but they evolve so quickly ...
Is not the same thing as it is a Element method, not NodeList one, so you will would need to map it instead. Because NodeList doesn't have the .map method you would also need to transform it to a Array first.
So the actually drop-in replacement of `$(foo).closest(bar)` would be something like:
That's not exactly the same, I don't think, because jQuery will give you all the `ul` that are closest to `.sth`, not just the first. You'd have to write a loop over the list returned from `document.getElementsByClassName('sth')` to get the same behaviour (because it doesn't look like the standardised `closest` works on lists.)
are we doing CORS? Adding headers? If it is just a one-off fetch, I'd probably long-hand it. If I intended to be fetching from many endpoints, I'd probably write a tiny little abstraction. I'm not exactly keen on loading a 30kb lib (gzipped) so that I can write (maybe) fewer lines for data fetching. Especially considering jQuery's async requests don't conform to the fetch standard. (They reject on 404s)
Hah. My first "web apps" were CGI scripts back in 1995. I know enough about the DOM to know that it sucks: document.getElementById is too verbose. I can either define my own function as a shortcut, or use a standard approach for the same. jQuery is that standard approach.
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:
Most IDEs will allow you to see what dqsA aliases by mousing over. I don’t really see a problem with it.
It also looks like the kind of thing a pre-commit hook could trivially expand if you’re working with other people who might find it in some way unacceptable.
for/of vs .forEach isn't the issue here. Frankly I almost always use for/of because it's implemented for all iterators and I prefer being outside of a function (e.g. I can use await).
All they did was alias `dqsA`. If anything, it's the fn name that could be better.
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.
Creating an array, populating it with however many elements just to be able to call some methods and destroying it immediately afterwards. And doing it all over the app, just because it's syntactically convenient. (all while you already have an iterable collection in the form of NodeList)
I'm also one of those guys that will always spread NodeLists (and other iterable-but-not-array type of objects) but it's really only because I find functional style a lot more readable than imperative style for loops. It might be iterable, but if it doesn't have map/filter/reduce and friends, might as well not be for me.
In every single project or company I've ever worked on/with, monkey patching was _extremely_ frowned upon (for good reasons).
Also, how would you be able to filter without any copies? you'd at least be forced to make one. filter is _not_ supposed to mutate anything. so you'd have to create a new Array and/or NodeList, and put the filtered values back in.
Even then, doing all this stuff for what is effectively one single copy that is likely to be insignificant at a performance level is, in my opinion, excessive. I just copy once and make the code clearer.
I see it a lot with other iterables, too. People may like one liners and functional style more than a procedural `for (of)` construct, so they use `[...iterable].any_array_function(...)` everywhere, except when foced not to by async code :).
Might also have something to do with Redux and immutable patterns. (the use of spread operator in general)
You probably shouldn't be making that query, unless you're doing something specific like web scraping and don't have control over the content of the site.
That's always been the blessing and curse with JQuery. It allows you to easily filter objects but it doesn't encourage efficiency.
A lot of people don't have control over the content of their site in enterprise situations. If you're stuck using an old framework or CMS you could be beholden to someone else. And at the same time there's a lot of devs who dgaf and just ship what works.
you could be using it already w/jquery though and if you just switched to the native selector it would stop working everywhere but safari.
"#some_combo:has(option:selected[value=..]) + .." seems like a reasonable way to conditionally target something to me, is it terribly worse than some other way?
Yeah, it's fragile and will easily lead to bugs when someone changes the markup without realizing it's going to break some crazy selector in another part of the code.
It would make a lot more sense to just add a class to the element you're trying to select.
it's a conditional select, you're saying just add code to add/remove a class to the target - of course, but that defeats the point of wanting a conditional selector in the first place
The point of selecting an element is to do something with it. How does selecting it by class defeat the point?
Look, if you need this for some one off thing and you've determined it's the best way to do it in this special case, it's not hard to create a function that will find the element you want.
It's not a good argument for using jQuery IMO, because if you're doing this regularly there's probably a better way to do it.
But coming soon™ you will be able to do even this with `document.querySelector`.
Edit: I didn't pay close attention to your second example. I was speaking mostly related to the a:has example before. Your second example seems to be something that would be desired more in CSS than JS, and I don't think it's unreasonable to do that in CSS. If you need to do it in JS you can workaround browser limitations just fine by writing more than one line of code to do the selection and test the condition.
For more advanced queries than standard CSS selectors provide, XPath is also supported by every browser and available via document.evaluate() (which is not eval() by the way)
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 crap is solved in a lot of places, jQuery is no longer the only library, and you don't need to support legacy browsers as much anymore, if at all
Companies are getting more security-conscious because of all the hacks and the pain of keeping old browser support is no longer outweighing the risks of upgrading is my theory.
For personal projects I'm far beyond caring about ancient browsers. In DayJob well hopefully soon be dropping support for IE completely. Unless someone is specifically paying me to care then I don't need help supporting truly legacy UAs.
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 don't know if that's such a good nitpick in practice. I want my code to crash if my assumptions aren't true - especially if I'm in the process of developing the code, I want to see big red errors and stack traces that point directly to the line that failed.
If it's meant to be the case that the element may or may not be present, then I'd much rather see an explicit check for that, than assume one thing and find out another later.
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'.
Thanks to cache partitioning, this is no longer true.
See, it turns out that by carefully leveraging cached retrieval of third party resources, scripts on two different domains can figure out if they are running in the same web browser, effectively pulling off browser fingerprinting.
To stop this, modern browsers don’t share third party resource caches cross domain.
So using a well known CDN no longer confers any benefit - even if a user has pulled down jquery for another site’s benefit, when they come to your site and you request the same resource, the browser will go out and re-retrieve it, to prevent you or the third party domain from being able to infer anything about the user based on the speed of the response or whether or not the request got made.
As others have mentioned this isn't the case, also the browser still has to parse that JavaScript, which for a lower end mobile phone is often significant.
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.
Fetch API is fine, but Axios[0] gives you a lot more flexibility. The best thing I like is the request/response interceptor. You can do cool stuff like injecting tokens into outgoing requests, retry failed requests, centralized error handling. Because of adapters, it works both in browser environment as well as Node.js environment. Heck, you can even mock requests in your unit tests using a mock adapter[1] to avoid making actual HTTP requests. Sure there is a cost for adding dependency when you can just use native APIs, but in this case, I think it's worth it.
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.
I worry too about people not considering accessibility.
This isn't a complaint you can level at the gov.uk team. They're obsessed with accessibility. Gov.uk is probably the best example of a well-designed, well-built, completely accessible website on the whole internet.
Hmm, I would agree that you can do 95%+ of stuff jQuery used to be used for in vanilla js or html/css in a nicer way but animated collapsible divs still require a stupid amount of js to achieve.
In 2020, a collapsible section is a matter of adding / removing a classname and a CSS animation; there's a few ways to do so, using jQuery is one, but you don't need thousands of lines of a JS library (network bandwidth + JS interpretation) to achieve that.
I feel like this solution feels subtly "wrong" if you're animating, because that high max height will be arbitrarily far away from where you'd normally want to animate to. Doubly so for easing out.
You bring up some interesting concerns. It's a good example of why there isn't a one size fits all answer. The UK gov site has high standards for these kind of things so will do it right anyway, but for a small shop leaning on a framework makes a lot of sense
If you've been using jQuery for years, know it, and can write a good amount of code without looking at a reference, then by all means, keep using it. It's not going anywhere anytime soon.
Except we've become so used to loading multiple megabytes of JS even on a simple blog post, that a 30KB library probably won't make a noticeable difference. Insofar as file size is concerned, I'd much rather pull in jQuery than some random npm package that depends on god-knows-how-many other random packages.
Even GOV.UK, an incredibly lean website by today's standards, only noticed a 10% difference in their benchmarks.
This is not the case anymore but I remember when Angular was including a version of jQuery, and having methods like "doSthAsInJquery" (paraphrasing) in Angular, and I could still hear everyday that Angular didn't have the overhead of including jQuery.
I wish we could have standardized in the Linq-like API of jQuery.
To add: jQuery is a pretty huge library for what it does. Talking both bundle size and execution speed. Not that the latter is noticeable for most cases, but it's still a cost. The question is: What for?
The primary use case for it has been cross browser compatibility plus a bit of sugar. The former is _gone_ and the latter is easily replaced with a few lines of JS. Then there is an ecosystem of libraries and components around it. Many of them have ditched jQuery or have provided an API that doesn't require it.
It adds tens of milliseconds to just downloading on a fast connection, plus it has to be parsed before what ever you need it to do will be functional.
To compare, just roughly:
For roughly the same size you can get declarative/reactive rendering with React, or an optimized FP standard library with ClojureScript, or data driven visualizations with d3 (roughly 2x the size).
For a tenth of the size you can get stuff like htmx, or a json validation library (avj), or like someone said Preact (React alternative).
But for jQuery, you're paying that for basically nothing the browser APIs don't already provide. It was a godsend 10y ago, but with legacy browsers finally fading out, the last one being ie11, you really don't _need_ it anymore.
One of the explicit goals of gov.uk is to be maximally accessible, and that includes for people accessing the Internet on a potato or who have a metered connection.
>> 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.
Definitely not Fetch. I don't believe anyone can argue that Fetch is more complicated.
I think this really seems to stem from a "I'm only used to jQuery, anything else is a big mental effort to learn and I'd rather stick with what I know".
I get it. Vanilla JS, if you're not used to it, is scary. But if you're advocating for jQuery "for simple interactions", and assuming it's simpler than vanilla JS, at some point you should ask yourself if you're just letting your skills stagnate, and staying stuck in the past. You owe it to yourself to update your skillset. If you decide you still need jQuery (e.g. maybe you need a plugin/library that requires jQuery), then fine. But at least you'll be making an informed decision, not a FUD-driven one.
As someone kinda obsessed with handcrafting all of its software without any dependency and is highly used to dom operations, I can't but thing you're making it much more of a deal than it is.
Handcrafting JavaScript applications without jQuery is possible, the real question though is: is it convenient if you like and find productive using jQuery? Here's a fact: you can always remove jQuery later when the product is mature and standards understood and there is time budget for it.
If that is literally the only wrapper you need, sure go ahead.
But most of the time, you find you need another wrapper, and then another, and the next thing you know you have most of jQuery, just not as uniform or as well tested.
Then compare it with dog's and pick the simpler one :) I don't know what's wrong with a utils.js file that only has what you need in a way that fits your project exactly. Woof.
Yup. Because the size of the library and the execution time just isn't that big of a deal, it's something people seem to obsess over but it doesn't really matter much.
Fully agree, and your example is still relatively simple. Method chaining in jQuery allows for extremely expressive one-liners that would require a huge amount of boilerplate in vanilla JS.
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.
I've used jQuery at 2 of the 3 companies I worked for. It can take you very far. Frankly some of the critical features, like making selecting element easier/shorter, should have been ported into JavaScript long ago. I think jQuery is still around largely because it makes, otherwise vanilla, JavaScript easier to use.
jQuery is still around because it's hard to get rid of. Think of all those WordPress websites that use themes, which have jQuery in it. Who is brave enough to remove jQuery?
I don't; it was an improvement when BackboneJS came out so I could reason about larger scale applications, and another improvement when AngularJS came out so I could build and write tests for logical, reusable components, and another when React (especially in 2022) was there and reduced these components to simple JS functions.
That said, I don't like how complicated modern day front-end development is, to the point where you need a university degree to even try and fathom some of React's inner workings (e.g. https://reactjs.org/blog/2019/11/06/building-great-user-expe...) etc.
Oh god, Backbone. I absolutely hated that framework. It didn't even seem to do anything, it seemed like I had to implement all of the logic myself. Except I had to do it their way, for some reason, and practically nothing made sense. (I haven't touched it in years, though, so my memory is probably distorting my experience)
I like the idea of React, just not what it has turned into. The amount of tooling that it has created to do things that should be simple (but aren't because of the runtime and/or the programmer), and the gymnastics it goes through so that people can have their precious (often unnecessary) SPAs, is ridiculous. That, and JSX continues to be an abomination that shits all over separation of concerns so that smoothbrains don't hurt themselves trying to reason over it.
I remember doing pocs with observables, angular and react back when they were all way new and thinking observables really makes the other two unnecessary.
We found it to be about 32kb gzip+minified in our builds. I just dropped it from one of our apps, where it wasn't even used except in a legacy logging module. We replaced the ajax call with XHR. The other app we maintain has it as well, again only for the ajax method.
While it may be nice, for large production apps we'll take the filesize gains where we can find them.
Our product is used by all sorts of devices and resources. Many use it on super old hardware in different countries. 32kb isn't much, but when you're analyzing Time To Render metrics, you might be surprised how little is necessary to move the needle.
That said I don't expect a massive impact from this change, but removing unused code is going in the right direction.
Then, on the other side of things, every fast food android app is ~60 MB. Even Five Guy's is 45 MB. Why? They all do the same thing, and none of the data that is used is included in the app, and all the logic might as well be the same.
And then on top of each restaurant app, you also have Uber Eats, Door Dash, etc., which again, basically so the same thing.
There should really be a single fast food app, I select my restaurant, and it shows me the options (which is basically google maps with mobile websites that would actually work). There's no reason for every restaurant and delivery service to have their own app.
AFAIK (I'm not a front-end dev but tried some) vanilla JavaScript has much of the things jQuery provided built-in nowadays yet they look much longer.
Now as JavaScript accumulated a lot of legacy stuff only kept for compatibility + also numerous verbally/syntactically sub-elegant APIs IMHO it is time to design a language which would simply be "better JavaScript" - clean, modern and elegant yet have no fundamental differences so it would be very easy to transpile by just string replace/mapping, essentially just a lightweight "syntactic sugar+discipline" layer. Then it can be integrated in browsers directly.
> design a language which would simply be "better JavaScript" - clean, modern and elegant yet have no fundamental differences
JS' problem is that it is fundamentally not "clean, modern and elegant". It was designed in a couple of days. And all the greatness that's added to it nowadays is done in a much better design process than at it's inception, yet some choices made at it's inception can never be reversed.
I've written some Elm and think it is phenomenal at being a better JS; but it fundamentally very different. Rotten fundamentals are notoriously hard to fix; especially when a lot has been built on top and needs to keep running.
AFAIK Elm can not be considered "a better JavaScript" because it not only is fundamentally different, it also is not fully self-sufficient - in many cases you have to resort to JavaScript pieces while engineering an Elm app.
The future will probably be that anything complicated enough to require frameworks like React will eventually move to web assembly, then you are free to use a newer language or compiler which strips out legacy mistakes and old sites can keep shipping their binary which will always work. Already a few of the complex web apps have become webasm.
Good policy, but also not huge gains here IMO. I wouldn't choose jQuery as I can do everything I need without it, but I also don't know of any serious issues it represents if it hangs around here or there.
I have a bunch of old code that uses jQuery, it works, everything new is vanilla but otherwise it's not a big impediment / problem that I find.
My take on this is, if you are writing enough JS in your app that the “terseness” of jQuery seems appealing you maybe shouldn’t be writing jQuery or vanilla (unless you’ve built a really nice framework/library specifically for your app/use case/whatever). My point is (I think) jQuery was/is best suited for “sprinkles” of js. These days with “sprinkles” of js jQuery isn’t worth the download/parse cost. If you have more than “sprinkles” use Svelte or Preact or Solid or React or Vue or Mithril or whatever.
The gains aren't massive — certainly not something any human using the site would notice (about 20ms faster to render pages for the average mobile phone user).
Still good to remove unncessary dependencies, though.
Not on an individual scale, no, but when you consider the millions of visits and views they get per year it adds up from a global / zoomed out point of view.
I'm sure with some math you can make a calculation on how much bandwidth and energy was saved with this One Clever Trick.
A government is the perfect place to look at this "zoomed out" view.
Your citizens an average rate of pay of Y per year. Some of time they save by getting stuff done on a government website will be put into getting more economic work done. If the citizens do 10 billion pageviews of gov.uk per year, and you shave off 20ms, thats 27 human-years of work per year. So it is certainly worth making this optimization, even if it takes a few people a few months to figure out how to remove jquery.
Aside from jQuery, I'm just amazed at how good the gov.uk is. They're comprehensive and accessible. Isn't this the pinnacle of government websites? I only wish that our government site (Japan) is half as good.
The older browsers which shaped jQuery’s design aren’t in use any more but you’re still paying for the code which now largely duplicates built-in features. For example, if I use querySelectorAll I’m using the browser’s native CSS parser and getting a native NodeList back - all of the work is being done in some of the most optimized C++/Rust code in existence. If I use jQuery, there’s a lot of code which has to parse that selector, build data structures, etc. and some of that is working around limitations which haven’t been an issue since IE6 was released. It’s not as bad as a full virtual DOM, there are a lot of smart optimizations there but it’s still running a lot more non-native code & memory which inevitably adds up on a large project. On older devices with less RAM and memory, this is a lot more noticeable - especially if those are Android devices which started at half the equivalent iOS performance when they were new.
The other problem you get is common to a lot of frameworks: it’s good that you can get a lot done but that means you can get s lot further without learning how it works underneath and by then you don’t want to revisit all of that code. This is especially easy to miss when your developers all use fast systems - React 3+ orders of magnitude slower isn’t noticeable on your $5k MacBook Pro but it might be when your grandfather tries to use that site on his 2011 PC, and by then you probably don’t want to do a messy refactoring on a large codebase.
"Older" in those lines isn't fungible. E.g. jQuery's older browser would be IE 9 while Gov.uk's older browser would be IE 11 (they do have limited support for back to 8 though but it's not expected to be matching).
jQuery never did make the migration to being packaged/delivered as a modern (i.e. post-2015) JavaScript module. This precludes it from being used in a lot of modern JavaScript workflows.
No matter what the library itself provides, to use it you have to go back to working like how developers in 2014 and before used to work with JavaScript, so that's a very real consideration that the "I still like to use jQuery" folks never mention. Are they writing all of their code as pre-2015 'classic' JavasScript as well?
The more Jq goes out of fashion, the better it becomes, because it means it stops changing and you can rely on it for decades. The other framework that looks interesting is htmx
I'm using HTMX with Flask through revamping a site previously with server side page rendering + AJAX. It is excellent.
Some of the more contrived AJAX to update parts of a page is being replaced by HTMX, some page loads are being replaced. It is working very smoothly and at a vastly higher speed (also, incremental) than redoing everything with React, the other option tabled. I'll certainly be using it more.
I love jQuery like I love a roll of duct tape. I'll use it for anything and everything but I also don't mind if a commercial jet would not like to showcase it.
var request = new XMLHttpRequest();
request.open('GET', '/my/url', true);
request.onload = function() {
if (this.status >= 200 && this.status < 400) {
// Success!
var data = JSON.parse(this.response);
} else {
// We reached our target server, but it returned an error
}
};
request.onerror = function() {
// There was a connection error of some sort
};
Having read the vast majority of comments it seems some people think jQuery is unnecessary/obsolete. Others say it's API is better, more concise, more flexible, etc.
As a newbie I decided to learn vanilla JS as I was too confused with the state of the various frameworks; I mean what one would you choose to start with?
That said I'm interested in what jQuery can do that vanilla JS can't.
If you know nothing about jQuery, you can guess what that does. Of course, you can do it in vanilla JS too. However it's a little harder to write and (more importantly) read.
jQuery is very comfortable and succinct for some DOM manipulation here and there. That is, when you need to sprinkle HTML with a bit of JavaScript.
But if you're starting today and want to have it easy in your career, learn React or Vue. They pay better and they look good in your CV. And I say that as someone who likes jQuery.
I never consciously made a decision to stop using jQuery, but after moving to frameworks like Svelte, there's just not a need for it most of the time (it's been years since I last added jQuery to a project, and I think that was only because I was using some third party lib that depended on it). YMMV of course.
Can someone ELI5 what's wrong with jQuery? People complain about 30 kilobytes jQuery consumes. But at the same time their 5mb minified react babellized gulped uglified webpacked blob is alright to load. Is there anything else that is missing?
Can't answer your question. I'd like to second the question however; our contemporary tools usually generate far larger and totally obscured components that marshal dependences from every corner of the internet using fabulously complex and fragile tooling.
I've done work using jQuery and several of the modern stacks and maintain much of it today. When I have to dive back into this work the jQuery stuff is usually painless. The Angular/React/etc. stuff causes an internal groan; even weeks after 'finishing' one of the latter some significant fraction of the tools and libraries are obsolete and the first thing you find yourself squandering time on is nursing it all into shape again. Years later you're also faced with either clinging to the old idioms that have been supplanted by 'better' ones or reworking a bunch of stuff. jQuery has never inflicted this problem on me.
Also, I don't really buy the "you might not need it" argument. jQuery reduces cognitive load by normalizing most of what you need to do to a vanishingly small and less error prone API. There is real value in that. jQuery delivers far more than just backfilling.
While I have a hard time imagining a client in 2022 that is so anemic that the cost of jQuery actually matters, it appears gov.uk has convinced itself that the removal of jQuery is a triumph for their use case. I've never had to deal with that use case. I doubt most people have or ever will. And so I take all of this with an appropriate grain of salt; if it's a choice between productivity and shaving a few points in blocking percentiles I'll take the former every day and twice on Sunday and the people that pay me are grateful that I do.
I learned about htmx in the comments of this discussion. I'm definitely going to give that a spin at some point. Thank you HN.
I've noticed this a trend lately. Why does everyone suddenly hate jQuery?
Instead, I've noticed everyone re-inventing the wheel. Take Bootstrap5, which "eliminated jquery and we wrote our own!" but now, it is much much larger. Then your next framework does the same, and so on, now we're downloading 1mb of javascript files just to display grandma's 160 byte tweet.
Nobody "hates" jQuery. Code and libraries are a liability. All people care about is getting their job done and going home.
This "trend" has been like 5+ years in the making. And it's simply a result of jQuery becoming less necessary as core JavaScript in the browser gains features.
One particular reason is that it can be hard to avoid or get rid of, if you are using third party UI modules- even "modern" ones, intended for use in a framework like Angular, might use jQuery as a dependency.
This is also problematic if your project has a dependency tree that needs multiple (incompatible) versions of jQuery.
It's a tool. If you need a hammer but use a screwdriver, then that's a problem.
jQuery made animation and such easy to do. But now we have CSS for that.
There's no value in chest pounding and proclaiming "Tool X is stupid. No one should use Tool X." Given the diversity of the internet, it's naive to believe you understand every possible use case. Just let it go already.
I don't use jQuery any more but I do use lodash because I appreciate that the methods are built to handle nulls. Methods like .forEach in the browser were for some odd reason chosen to be instance methods so you always have to check for null/undefined before calling them.
Bravo gov.uk, the design/web team do a fantastic job. I'd be the first on the bash-the-government bandwagon but their work is exemplary. If they can work with modern js alone and still be compatible to people on Safari 9 and IE11 then respect to them!
We don't know what else was done to the site while jQuery was removed.
I would assume that the British government had considerable resources to put on the rewrite so it's quite possible that the removal was part of a general site refresh.
According to the Matt Hobb's twitter thread, they had to do a lot of work to get rid of the JQuery dependency. Does anyone know what kind of challenges they encountered along the way?
It is not about update but dependence of unknown or uncontrolled chain. It is a start to look at what you are really using and reduce the surface of risk.
I don't mind so much gov.uk using jQuery, but I noticed recently that the UK government's 'parliamentlive.tv' has a dependency on jQuery loaded from Google's CDN, when there was a Google outage in the country I live in (I think it was something to do with routing on Vodafone's side, rather than an actual Google outage).
I see that's now removed, but Recaptcha is still there. The site works without it, but it seems a bit odd to me that by default, my data is shared by my government with a third party company when I want to participate in democracy online.
bullshit. there are tons of images in this site most are above 10kb, there are several images I could find which are above 20kb.
Jquery is passive, just loading jQuery in the page itself doesn't do any harm. could be some plugins they are using might be doing something unnecessary.
Most developers don't seem to understand that jQuery was not just a wrapper for browser compatability. Yes, we do have all that nice functionality in a modern browser nowadays but compared to jQuery it just not as elegant. jQuery still has a place.
You are correct sir. I was trying to keep myself going on a rant.
I think if you want to avoid large frameworks/build pipelines and the ugly mess that Web APIs are then jQuery fits perfectly. I have tried and failed many times writing vanilla JS for some smaller projects but always end up over budget and with code ending up looking like a worse version of jQuery.
Only if you have large enough visitor count and team then using vanilla API makes practical sense because you might save couple GBs of web traffic and that is nice to see.
The bashing of jQuery comes from junior devs. Of course a VDOM is clearer, more productive (and less performant) however most webapps with a minimum of logic have many legitimate uses of native dom/jquery in addition to the VDOM. And the interaction is perfectly safe as long as you do native DOM in the right lifecycle method (mounted).
jQuery is a pleasure to use and give us a lot of power/expressivity.
More generally this vague of juniors devs (e.g. CSS-in-JS lobby) are becoming less and less familiar with the concept of CSS/DOM selectors, despite their awesomeness and uniformity both for DOM operations, styling operations and integration tests operations (cypress)
BTW a little known fact is that jQuery is not just sugar and cross-browser consistentcy, in fact it push the boundaries of what is possible vs native CSS, see e.g. the reverse direction paradigm shift of https://api.jquery.com/has-selector/
Although its true that augmenting jQuery with a batcher for performance doesn't seems currently possible?
https://github.com/wilsonpage/fastdom
Not sure you read the submission, but the move away from jQuery was not to move to anything "virtual DOM"/React/similar but rather that the functions provided by jQuery now have vanilla/"native" alternatives.
I do think that your complaint, while applicable to a lot of websites, is not specifically applicable to GOV.UK. They do everything to use plain HTML (and if possible no Javascript at all, but there are certain pages where Javascript is an absolute must like interactive maps), and they aren't using React but instead a special framework that is designed to minimise Javascript even to novice developers. Basically they've replaced jQuery with plain Javascript since that some older devices they're supporting (which jQuery is a better solution as it's bug-tested and optimised as much as possible) is dead.
The main value I found with jQuery was that the more your CSS selectors and jQuery selectors diverged, the more it felt like you were doing the same work twice.
Now I'm curious what the CSS looks like for devs who have only ever known VDOM frameworks. Regular CSS can be pretty bad, particularly on a mature project. Are we talking dumpster fire or three ring circus here?
When jQuery was in its prime, stubbornella was a fixture of youtube playlists. One of the feathers in her cap was cutting yahoo's CSS in half, which resonated with a lot of us. CSS has been problematic for a long time.
I used to hate code generators because the code quality was always so bad that if a midlevel or senior dev was writing code like that I'd be talking to our manager about firing them, and for a junior dev we'd be talking about more intensive mentoring or even a PIP.
Once Sass introduced SCSS, that was the first code generator I ever met that actually impressed me, and Less is very close. The default CSS out of it looked very much like the sort of CSS you would expect from a project after someone had already gone through and cleaned up all of the cliched failure modes for medium sized projects. It felt like having a fast forward button. Still one of the fastest 'sells' for me, and I do quite a lot of technology selection for projects.
Not that it's perfect. Poorly written mixins/functions can generate way more CSS per call than is necessary, and I have a team of overbooked people that I need to sell on prioritizing fixing this sort of thing and I just can't find the bandwidth because there are always 2 more pressing issues I need to talk to them about. I can't squeeze blood from stone, and I can only ask for personal favors about as frequently as I can grant them, modulo any turnover - which has become a problem. Turns out if I take a shine to you, you're also really easy to hire somewhere else.
I don't know if you've ever used gov.uk, but I have literally no complaints about it (other than a few content-level ones, which the web design team can't help with). It's honestly a brilliant site.
There is also excessive praise for Gov UK design system that takes up half of the vertical space with cookie banner, flash messages, and navigation bar. It has so much useless negative space.
I would give it 5 marks out of 10. It’s decent but not a bastion of good design.
While I haven't experienced USWDS deeply, that's kind of a problem in itself. A good design that doesn't get deployed is just that - a design. Gov.UK might not be pretty but it's consistent across different ministries, departments and instrumentalities which helps tremendously, but US government websites, even if restricted to the federal level, is a mess that I would prefer to hold my tongue at the inconsistency. What is GAO's plans to deploy them at least at a federal level? Is there even a plan? By the way, it's not solely Gov.UK which has this level of consistency (Singapore comes to my mind) so it's not a unique property.
jQuery isn't a framework though (that's half of why I like(d) it). Or are you talking about the number of lunatics on both sides of the argument crowding out everybody else?
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.