7 ms·

Eh. Everyone hates on jQuery, but for most informational sites that's really all you need for basic interaction. Speed really isn't bad, and it's so straightfo

Eh. Everyone hates on jQuery, but for most informational sites that's really all you need for basic interaction. Speed really isn't bad, and it's so straightforward that it's hard to mis-use at this point. I seem to have way more issues with newer frameworks/SPA if I'm not using chrome with no extensions. Makes me nervous dealing with important stuff like banking or government sites.

jaywalk 4y ago
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.
- andybak 4y ago
  It's a much nicer syntax and has a ton of useful helpers. Vanilla js for similar things just looks like someone has waved the ugly stick at it. There are sound arguments against jQuery but the "you can just use vanilla" is the least convincing.
  - jaywalk 4y ago
    Not having to load yet another JS library on your page if you don't really need it is a pretty good argument, I'd say.
    - sofixa 4y ago
      OP's argument is that jQuery is all you need for basic use cases, so that'd be the only JS library loaded.
    - kijin 4y ago
      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.
      - Deukhoofd 4y ago
        A 10% performance gain is quite a big deal, I wouldn't just shove it under the table like that.
        Dudeman112 4y ago
        Like every % comparison, it depends on the baseline. Cue all the people going on about big O for parts of the code that are indistinguishable from noise in actual benchmarks.
    - andybak 4y ago
      Yes. You'll note that I already anticipated that in my original point. I was very specific in how I worded it for good reason.
    - dgb23 4y ago
      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.
      - rtpg 4y ago
        30kb minified and gzipped! Less than most hero images. It's a nice API for simple stuff. I think if you strip out the AJAX support it can get extremely tiny.
        Rumudiez 4y ago
        30kb gzipped is still 10x larger than Preact for reference
        SemanticStrengh 4y ago
        that doesn't make it an issue in any way, it's not a numbers competition unless you have a 56K
        Smaug123 4y ago
        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.
        lowwave 4y ago
        or use https://axios-http.com/ https://axios-http.com/ for ajax stuff
        dgb23 4y ago
        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.
    - mejutoco 4y ago
      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.
- spicybright 4y ago
  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.
  - pacaro 4y ago
    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
  - Cthulhu_ 4y ago
    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.
    - have_faith 4y ago
      Can CSS transitions and animations handle animating to auto height/widths yet?
      - d1sxeyes 4y ago
        I don't think so. One trick I've used to good effect is setting an high max-height, then translating by 100% and removing pointer events.
        flatcakes 4y ago
        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.
- seydor 4y ago
  i see a lot of const $ = document.querySelector.bind(document);
- jenscow 4y ago
  Right. However, jQuery isn't just for cross-browser. It provides a clean API for manipulating the DOM, as this site demonstrates (which is ironic): https://youmightnotneedjquery.com/ https://youmightnotneedjquery.com/ Personally, for simple sites, I aim for vanilla JS but use jQuery (cash, actually) where it makes sense - such as working on collections of elements.
  - SemanticStrengh 4y ago
    for real its superior ergonomy is painfully obvious
- deleted 4y ago
  [deleted]
- criddell 4y ago
  You can do quite a bit without Javascript too. A lot of websites don't need much more than simple menus. Steve Gibson's site is an example: https://www.grc.com/default.htm https://www.grc.com/default.htm
philliphaydon 4y ago
I loved jquery back in the day. It made web development bearable in a time when it was a clusterfuck. I think a lot of people owe a lot of thanks to jquery. But in 2022 vanilla javascript is all you really need.
- dsego 4y ago
  jQuery still offers a much nicer experience. The built-in dom apis are neither very elegant nor ergonomic. // jquery $(selector).on('click', fn) // vanilla js document.querySelectorAll(selector).forEach(el => el.addEventListener('click', fn) )
  - bennyp101 4y ago
    It takes 1min to write a wrapper around that, though. Having said that, for the sake of 25kb - if you use more than a handful of features you might as well just include it.
    - mkoryak 4y ago
      That's the problem. It takes only 1 minute to write a wrapper, so you will write one, and I'll write one, and your dog will write one.
      - tiborsaas 4y ago
        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.
        mkoryak 4y ago
        your dog will not look for a simpler impl before making one. your npm's dependencies authors cat will write a small wrapper and wont know about yours.
        4y ago
nojs 4y ago
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.
duxup 4y ago
I will always think fondly of jQuery. It did a great job for what it was intended, saved a lot of time. jQuery's time has passed, and that's ok too.
phkahler 4y ago
>> 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.
- AdrianB1 4y ago
  For AJAX, jQuery is still simpler than vanilla JS.
  - barbecue_sauce 4y ago
    Even fetch?
    - moreira 4y ago
      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.
      - easrng 4y ago
        I mean `await $.ajax("https://jquery.com/ https://jquery.com/")` is shorter than `await(await fetch("https://jquery.com/")).text https://jquery.com/")).text()`
deleted 4y ago
[deleted]

jaywalk 4y ago

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.

andybak 4y ago
It's a much nicer syntax and has a ton of useful helpers. Vanilla js for similar things just looks like someone has waved the ugly stick at it. There are sound arguments against jQuery but the "you can just use vanilla" is the least convincing.
- jaywalk 4y ago
  Not having to load yet another JS library on your page if you don't really need it is a pretty good argument, I'd say.
  - sofixa 4y ago
    OP's argument is that jQuery is all you need for basic use cases, so that'd be the only JS library loaded.
  - kijin 4y ago
    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.
    - Deukhoofd 4y ago
      A 10% performance gain is quite a big deal, I wouldn't just shove it under the table like that.
      - Dudeman112 4y ago
        Like every % comparison, it depends on the baseline. Cue all the people going on about big O for parts of the code that are indistinguishable from noise in actual benchmarks.
  - andybak 4y ago
    Yes. You'll note that I already anticipated that in my original point. I was very specific in how I worded it for good reason.
  - dgb23 4y ago
    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.
    - rtpg 4y ago
      30kb minified and gzipped! Less than most hero images. It's a nice API for simple stuff. I think if you strip out the AJAX support it can get extremely tiny.
      - Rumudiez 4y ago
        30kb gzipped is still 10x larger than Preact for reference
        SemanticStrengh 4y ago
        that doesn't make it an issue in any way, it's not a numbers competition unless you have a 56K
        Smaug123 4y ago
        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.
      - lowwave 4y ago
        or use https://axios-http.com/ https://axios-http.com/ for ajax stuff
      - dgb23 4y ago
        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.
  - mejutoco 4y ago
    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.
spicybright 4y ago
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.
- pacaro 4y ago
  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
- Cthulhu_ 4y ago
  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.
  - have_faith 4y ago
    Can CSS transitions and animations handle animating to auto height/widths yet?
    - d1sxeyes 4y ago
      I don't think so. One trick I've used to good effect is setting an high max-height, then translating by 100% and removing pointer events.
      - flatcakes 4y ago
        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.
seydor 4y ago
i see a lot of const $ = document.querySelector.bind(document);
jenscow 4y ago
Right. However, jQuery isn't just for cross-browser. It provides a clean API for manipulating the DOM, as this site demonstrates (which is ironic): https://youmightnotneedjquery.com/ https://youmightnotneedjquery.com/ Personally, for simple sites, I aim for vanilla JS but use jQuery (cash, actually) where it makes sense - such as working on collections of elements.
- SemanticStrengh 4y ago
  for real its superior ergonomy is painfully obvious
deleted 4y ago
[deleted]
criddell 4y ago
You can do quite a bit without Javascript too. A lot of websites don't need much more than simple menus. Steve Gibson's site is an example: https://www.grc.com/default.htm https://www.grc.com/default.htm

philliphaydon 4y ago

I loved jquery back in the day. It made web development bearable in a time when it was a clusterfuck. I think a lot of people owe a lot of thanks to jquery. But in 2022 vanilla javascript is all you really need.

dsego 4y ago
jQuery still offers a much nicer experience. The built-in dom apis are neither very elegant nor ergonomic. // jquery $(selector).on('click', fn) // vanilla js document.querySelectorAll(selector).forEach(el => el.addEventListener('click', fn) )
- bennyp101 4y ago
  It takes 1min to write a wrapper around that, though. Having said that, for the sake of 25kb - if you use more than a handful of features you might as well just include it.
  - mkoryak 4y ago
    That's the problem. It takes only 1 minute to write a wrapper, so you will write one, and I'll write one, and your dog will write one.
    - tiborsaas 4y ago
      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.
      - mkoryak 4y ago
        your dog will not look for a simpler impl before making one. your npm's dependencies authors cat will write a small wrapper and wont know about yours.
      - 4y ago

nojs 4y ago

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.

duxup 4y ago

I will always think fondly of jQuery. It did a great job for what it was intended, saved a lot of time. jQuery's time has passed, and that's ok too.

phkahler 4y ago

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

AdrianB1 4y ago
For AJAX, jQuery is still simpler than vanilla JS.
- barbecue_sauce 4y ago
  Even fetch?
  - moreira 4y ago
    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.
    - easrng 4y ago
      I mean `await $.ajax("https://jquery.com/ https://jquery.com/")` is shorter than `await(await fetch("https://jquery.com/")).text https://jquery.com/")).text()`

deleted 4y ago

[deleted]