4 ms·

It’s worth remembering that jQuery is a ~30kb “cost” for the end user. Once upon a time, that was a lot. And it was entirely prudent to question its necessity o

It’s worth remembering that jQuery is a ~30kb “cost” for the end user. Once upon a time, that was a lot. And it was entirely prudent to question its necessity on the basis of load times and bandwidth consumption. But now we live in a world where many common web pages have over 1000kb of resources on them. And nobody blinks an eyelid.

manigandham 5y ago
Unfortunately this kind of thought process is what leads to pages with megabytes of JS. Every byte matters.
- mkoryak 5y ago
  This is especially true because now instead of all your dependencies using jQuery, they are each implementing a small subset of jQuery on their own. The problem you thought you solved was actually made exponentially worse when those dependencies dependencies also rewrote some jQuery using different native methods
- sanitycheck 5y ago
  But, we didn't used to have megabytes of JS on pages back when everyone used jquery. I think what leads to pages with megabytes of JS is when people automatically assume that all projects must be a SPA built on one the popular everything-but-the-kitchen-sink frameworks.
- simondotau 5y ago
  But it isn’t a one-way street. Using jquery can eliminate the need for other, lengthier blobs of code. In fact that’s exactly what this “vanilla JavaScript alternative” does.
fabiospampinato 5y ago
I'm not sure I buy this argument, one can't just say that ~30kb isn't a lot because 30 is a number perceived as low, would 30kb be justified for a library that allows you to toggle a class on a node? Of course it wouldn't, you need to measure what you are getting for 30kb. I don't buy the second part of the argument either, you can load a 1000kb image on a blog post and that won't have nearly the same effect as loading 1000kb of JS. The JS needs to be parsed and executed and maybe the site doesn't even work without it, the image can probably be rendered progressively, can be decoded in another thread, nothing is really waiting on it to load, and if it doesn't load at all it's not the end of the world anyway. With ~4kb you can have Preact, is jQuery Slim (~26kb) giving you ~6.5x times as much value as Preact really? Maybe it is, probably not. For some context I maintain a ~6kb rewrite of a subset of jQuery (https://github.com/fabiospampinato/cash https://github.com/fabiospampinato/cash), which IMO is much better value proposition for many use cases.
- simondotau 5y ago
  I get this, but my website is 150kb on first load with a stale cache, most of which is a ~50kb JS blob, ~10kb CSS blob and ~80kb of fonts. All these static resources are served from the cloud edge with Cloudflare and aggressively cached in the browser. (All quantities gzipped.) Subsequent pages are typically less than 10kb and are served from a geographic location near to 80% of my country-specific audience. The reality is my site (a discussion forum) has a substantially smaller footprint than just about any other similar site, let alone most Wordpress templates. The size of jQuery is, for me, outstanding value for the efficiencies it gives me. I have not checked out Cash but the main reason I use jQuery is for the ajax scaffolding which most alternatives don't offer.
sanitycheck 5y ago
Not just 1000kb. netflix.com (which doesn't even do anything): 1.6MB CNN: 3.4MB NYT: 4.1MB Guardian: 5.7MB IGN: 69.5MB I still use jquery when I'm targeting ancient devices. Some of them still run Presto. Performance is fine, file size is fine - and drastically smaller than any of the sites above! (I can see why one might not want jquery as a dependency of a dependency though.)
- t0astbread 5y ago
  Are you sure you weren't loading a video on IGN?
  - Ardren 5y ago
    Yep, looks like it's a video. But it's auto-preloaded and playing even when not visible...
- beebeepka 5y ago
  I used to work on low power/ancient devices running presto or blink. Performance was much better on opera 12.80 or so. At some point I had to support an outside team working on external application running inside ours. These guys used jQuery in ways it shouldn't be used when performance is an issue. Had to spend a few hours reducing their code to mostly CSS and just a tiny bit of honest to god js that even presto can understand and render. Point is, it's really easy to overuse and that can have an effect on performance, even on presto
  - sanitycheck 5y ago
    We may know the same devices - designed to run Flash Lite acceptably then made to just barely support HTML/JS with heroic engineering efforts later. Nobody believes how slow they are until they try. I think if someone queries the DOM a lot on these things, especially in response to keypresses, they're in trouble whether or not they're doing it with jquery.
    - beebeepka 5y ago
Wowfunhappy 5y ago
> And nobody blinks an eyelid. But maybe they should? Like, I agree that if your web page loads a full MB of Javascript, eliminating JQuery should be the least of your concerns; it's a drop in the bucket, so optimize elsewhere. But web pages really shouldn't be loading 1 MB of Javascript in the first place. It's so nice when I come across a website that's actually slim, I can really feel the difference...

manigandham 5y ago

Unfortunately this kind of thought process is what leads to pages with megabytes of JS. Every byte matters.

mkoryak 5y ago
This is especially true because now instead of all your dependencies using jQuery, they are each implementing a small subset of jQuery on their own. The problem you thought you solved was actually made exponentially worse when those dependencies dependencies also rewrote some jQuery using different native methods
sanitycheck 5y ago
But, we didn't used to have megabytes of JS on pages back when everyone used jquery. I think what leads to pages with megabytes of JS is when people automatically assume that all projects must be a SPA built on one the popular everything-but-the-kitchen-sink frameworks.
simondotau 5y ago
But it isn’t a one-way street. Using jquery can eliminate the need for other, lengthier blobs of code. In fact that’s exactly what this “vanilla JavaScript alternative” does.

fabiospampinato 5y ago

I'm not sure I buy this argument, one can't just say that ~30kb isn't a lot because 30 is a number perceived as low, would 30kb be justified for a library that allows you to toggle a class on a node? Of course it wouldn't, you need to measure what you are getting for 30kb. I don't buy the second part of the argument either, you can load a 1000kb image on a blog post and that won't have nearly the same effect as loading 1000kb of JS. The JS needs to be parsed and executed and maybe the site doesn't even work without it, the image can probably be rendered progressively, can be decoded in another thread, nothing is really waiting on it to load, and if it doesn't load at all it's not the end of the world anyway. With ~4kb you can have Preact, is jQuery Slim (~26kb) giving you ~6.5x times as much value as Preact really? Maybe it is, probably not. For some context I maintain a ~6kb rewrite of a subset of jQuery (https://github.com/fabiospampinato/cash https://github.com/fabiospampinato/cash), which IMO is much better value proposition for many use cases.

simondotau 5y ago
I get this, but my website is 150kb on first load with a stale cache, most of which is a ~50kb JS blob, ~10kb CSS blob and ~80kb of fonts. All these static resources are served from the cloud edge with Cloudflare and aggressively cached in the browser. (All quantities gzipped.) Subsequent pages are typically less than 10kb and are served from a geographic location near to 80% of my country-specific audience. The reality is my site (a discussion forum) has a substantially smaller footprint than just about any other similar site, let alone most Wordpress templates. The size of jQuery is, for me, outstanding value for the efficiencies it gives me. I have not checked out Cash but the main reason I use jQuery is for the ajax scaffolding which most alternatives don't offer.

sanitycheck 5y ago

Not just 1000kb. netflix.com (which doesn't even do anything): 1.6MB CNN: 3.4MB NYT: 4.1MB Guardian: 5.7MB IGN: 69.5MB I still use jquery when I'm targeting ancient devices. Some of them still run Presto. Performance is fine, file size is fine - and drastically smaller than any of the sites above! (I can see why one might not want jquery as a dependency of a dependency though.)

t0astbread 5y ago
Are you sure you weren't loading a video on IGN?
- Ardren 5y ago
  Yep, looks like it's a video. But it's auto-preloaded and playing even when not visible...
beebeepka 5y ago
I used to work on low power/ancient devices running presto or blink. Performance was much better on opera 12.80 or so. At some point I had to support an outside team working on external application running inside ours. These guys used jQuery in ways it shouldn't be used when performance is an issue. Had to spend a few hours reducing their code to mostly CSS and just a tiny bit of honest to god js that even presto can understand and render. Point is, it's really easy to overuse and that can have an effect on performance, even on presto
- sanitycheck 5y ago
  We may know the same devices - designed to run Flash Lite acceptably then made to just barely support HTML/JS with heroic engineering efforts later. Nobody believes how slow they are until they try. I think if someone queries the DOM a lot on these things, especially in response to keypresses, they're in trouble whether or not they're doing it with jquery.
  - beebeepka 5y ago

Wowfunhappy 5y ago

> And nobody blinks an eyelid. But maybe they should? Like, I agree that if your web page loads a full MB of Javascript, eliminating JQuery should be the least of your concerns; it's a drop in the bucket, so optimize elsewhere. But web pages really shouldn't be loading 1 MB of Javascript in the first place. It's so nice when I come across a website that's actually slim, I can really feel the difference...