5 ms·

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 o

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

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