4 ms·

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.

OP's argument is that jQuery is all you need for basic use cases, so that'd be the only JS library loaded.

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.