15 ms·

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

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.

narag 4y ago
I'm curious: what's replaced Query? I guess it's not a single library, but a set of frameworks...
- zelphirkalt 4y ago
  Plain JavaScript replaced it. jQuery provided useful things at its time, indeed, but JS has been somewhat improved at least and learned the tricks, even improved upon them. JS is still somewhat ugly, but I will give it at least that much. Now one does not really need jQuery any longer for most things, which were done with it. I personally find plain JS API and fetch to be cleaner than jQuery stuff even. People still use jQuery it out of habbit or, because it would be a lot of work to get rid of it everywhere.
  - petre 4y ago
    Fetch is fine but I'm not going to write document.querySelector every time I have to select some nodes, which happens quite often.
    - deleted 4y ago
      [deleted]
    - julianlam 4y ago
      That's fine, pretty sure browsers alias $ and $$ to querySelector and querySelectorAll already (although I could be very wrong) But speaking as someone who writes vanilla by default, it really really isn't as big an issue as you think it is.
      - petre 4y ago
        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.
      - pwdisswordfish9 4y ago
        > pretty sure browsers alias $ and $$ to querySelector and querySelectorAll already (although I could be very wrong) You are wrong.
kordlessagain 4y ago
> I think of this story whenever I see jQuery popup on Hacker News. There is always a strong contingent of devs who swear by this library. But to me, they are like the old grey beard who didn't update his knowledge as the times changed. This is a strawman argument. It's a biased view you hold. Because of that, you make up a story to match your biases around people who use such-and-such library don't think they need to update their skill set. I'm not angry about this, but am only pointing out biased arguments create dissonance. > I see a trend of well-written, evidence backed articles where large, well funded sites are making a case to deprecate jQuery. These fact-based investigations into problems faced by their dev team result in a reasoned decision to remove a dependency that no longer justifies its cost. I encourage everyone to introspect if their defense of jQuery is on an equal technical footing to these types of investigations. You read something somewhere about how jQuery is a costly dependency. Yet, there are no links that I can see anywhere in the threads here, nor a good rational argument for people to NOT use jQuery because it is a costly dependency. There are opposing opinions on this, but the opinions that it needs to be included via CDN don't address the fact it can be hosted locally and the opinions "who needs all that code to load?" don't take into account that browsers and networks are bonkers fast nowadays. Who cares if it's a bit more code? It's not like jQuery is growing its codebase at the rate compute and network speed increases. For that matter, could not the same argument be made of JavaScript itself? I taught myself Promises, not because I could stay "relevant", but because it makes good sense to write code that is easy to read and maintain, even if it is me doing both on my project. The code I produced when I wasn't doing Promises was "legacy" the second it hit the repo, and will be "costly" if someone else has to jump in and work on it to convert it to Promises, because they'll have to brain dump what I was thinking (or not) when I wrote it! This salt and pepper beard stays up on technology. I didn't really write code in the past, but now I'm great at what I do and I fully intend on exploring new technologies when they compliment what I can do rapidly in the frameworks and methods I well understand, if that's what it takes to get to market faster.
- girvo 4y ago
  > Who cares if it's a bit more code Well, Gov.uk for one, as per the article you're commenting on. As they pointed out: > Not everyone is tapping away on their 2022 MacBook Pro on a rip-roarin' broadband connection. GOV.UK has to be accessible to everyone, and that means keepin' it lean. > Here's a few of the greatest hits from Matt Hobbs on what GOV.UK noticed in removing jQuery: > - Less front end processing time overall. > - 11% less blocking time at the 75th percentile. > - 10% less blocking time for users at the 95th percentile. These are users who experience seriously adverse network and device conditions, and every performance gain matters especially for them.
niccl 4y ago
upvoted because this is a really good example of how to respond to criticism
lhorie 4y ago
IMHO this analogy doesn't really click, on multiple levels. Any old timer who uses jQuery surely is also aware of querySelectorAll and friends. There's even an entire website dedicated to catering to exactly that transition[0]. I don't think anyone defending jQuery is doing so out of a sense of hubris towards outdated knowledge, but rather because it ironically is more lightweight than a lot of the modern SPA craze, while still being more ergonomic than vanilla JS. To try to shoehorn this back into the compiler analogy, modern frameworks would be like the advanced, complex and opaque compiler, and the grey beard is the guy that understands how stuff like HTML streaming and font download prioritization and hidden classes affect performance, whereas the team lead is analogous to the run-of-the-mill bootcamp grad that knows how to use the framework-du-jour but is way out of their depth if venturing outside the comfort of the framework and into the depths of those advanced topics. And I think the gov.uk use case here might actually be an outlier in the sense that it actually considers performance of an already tight codebase, whereas a lot of jQuery deprecation efforts bring with them heavier alternatives in the name of maintainability or developer productivity or hiring or whatever. To be clear, many of these concerns are quite valid, but it seems a bit disingenuous to create a false dichotomy between understanding of low level concerns vs concerns about SDLC management. They aren't mutually exclusive. [0] https://youmightnotneedjquery.com/ https://youmightnotneedjquery.com/
- _HMCB_ 4y ago
  Thank you. That needed said.
- adrusi 4y ago
  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.

narag 4y ago

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

zelphirkalt 4y ago
Plain JavaScript replaced it. jQuery provided useful things at its time, indeed, but JS has been somewhat improved at least and learned the tricks, even improved upon them. JS is still somewhat ugly, but I will give it at least that much. Now one does not really need jQuery any longer for most things, which were done with it. I personally find plain JS API and fetch to be cleaner than jQuery stuff even. People still use jQuery it out of habbit or, because it would be a lot of work to get rid of it everywhere.
- petre 4y ago
  Fetch is fine but I'm not going to write document.querySelector every time I have to select some nodes, which happens quite often.
  - deleted 4y ago
    [deleted]
  - julianlam 4y ago
    That's fine, pretty sure browsers alias $ and $$ to querySelector and querySelectorAll already (although I could be very wrong) But speaking as someone who writes vanilla by default, it really really isn't as big an issue as you think it is.
    - petre 4y ago
      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.
    - pwdisswordfish9 4y ago
      > pretty sure browsers alias $ and $$ to querySelector and querySelectorAll already (although I could be very wrong) You are wrong.

kordlessagain 4y ago

> I think of this story whenever I see jQuery popup on Hacker News. There is always a strong contingent of devs who swear by this library. But to me, they are like the old grey beard who didn't update his knowledge as the times changed. This is a strawman argument. It's a biased view you hold. Because of that, you make up a story to match your biases around people who use such-and-such library don't think they need to update their skill set. I'm not angry about this, but am only pointing out biased arguments create dissonance. > I see a trend of well-written, evidence backed articles where large, well funded sites are making a case to deprecate jQuery. These fact-based investigations into problems faced by their dev team result in a reasoned decision to remove a dependency that no longer justifies its cost. I encourage everyone to introspect if their defense of jQuery is on an equal technical footing to these types of investigations. You read something somewhere about how jQuery is a costly dependency. Yet, there are no links that I can see anywhere in the threads here, nor a good rational argument for people to NOT use jQuery because it is a costly dependency. There are opposing opinions on this, but the opinions that it needs to be included via CDN don't address the fact it can be hosted locally and the opinions "who needs all that code to load?" don't take into account that browsers and networks are bonkers fast nowadays. Who cares if it's a bit more code? It's not like jQuery is growing its codebase at the rate compute and network speed increases. For that matter, could not the same argument be made of JavaScript itself? I taught myself Promises, not because I could stay "relevant", but because it makes good sense to write code that is easy to read and maintain, even if it is me doing both on my project. The code I produced when I wasn't doing Promises was "legacy" the second it hit the repo, and will be "costly" if someone else has to jump in and work on it to convert it to Promises, because they'll have to brain dump what I was thinking (or not) when I wrote it! This salt and pepper beard stays up on technology. I didn't really write code in the past, but now I'm great at what I do and I fully intend on exploring new technologies when they compliment what I can do rapidly in the frameworks and methods I well understand, if that's what it takes to get to market faster.

girvo 4y ago
> Who cares if it's a bit more code Well, Gov.uk for one, as per the article you're commenting on. As they pointed out: > Not everyone is tapping away on their 2022 MacBook Pro on a rip-roarin' broadband connection. GOV.UK has to be accessible to everyone, and that means keepin' it lean. > Here's a few of the greatest hits from Matt Hobbs on what GOV.UK noticed in removing jQuery: > - Less front end processing time overall. > - 11% less blocking time at the 75th percentile. > - 10% less blocking time for users at the 95th percentile. These are users who experience seriously adverse network and device conditions, and every performance gain matters especially for them.

niccl 4y ago

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

lhorie 4y ago

IMHO this analogy doesn't really click, on multiple levels. Any old timer who uses jQuery surely is also aware of querySelectorAll and friends. There's even an entire website dedicated to catering to exactly that transition[0]. I don't think anyone defending jQuery is doing so out of a sense of hubris towards outdated knowledge, but rather because it ironically is more lightweight than a lot of the modern SPA craze, while still being more ergonomic than vanilla JS. To try to shoehorn this back into the compiler analogy, modern frameworks would be like the advanced, complex and opaque compiler, and the grey beard is the guy that understands how stuff like HTML streaming and font download prioritization and hidden classes affect performance, whereas the team lead is analogous to the run-of-the-mill bootcamp grad that knows how to use the framework-du-jour but is way out of their depth if venturing outside the comfort of the framework and into the depths of those advanced topics. And I think the gov.uk use case here might actually be an outlier in the sense that it actually considers performance of an already tight codebase, whereas a lot of jQuery deprecation efforts bring with them heavier alternatives in the name of maintainability or developer productivity or hiring or whatever. To be clear, many of these concerns are quite valid, but it seems a bit disingenuous to create a false dichotomy between understanding of low level concerns vs concerns about SDLC management. They aren't mutually exclusive. [0] https://youmightnotneedjquery.com/ https://youmightnotneedjquery.com/

_HMCB_ 4y ago
Thank you. That needed said.
adrusi 4y ago
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.