Hacker News new | ask | show | jobs
by simondotau 1752 days ago
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.

4 comments

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), which IMO is much better value proposition for many use cases.

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.

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

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

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.

The lowest common denominator I had to deal with were some quite expensive, for the hardware, Arris devices. Roughly 10 times slower than a 2 core skylake and similar. I wish I was joking. As you say, people have no idea what slow is until they have to code for these.

I've played with some fairly decent machines as well. Quite a bit faster and cheaper but you can't just magically replacement millions of devices every time something new comes along

Are you sure you weren't loading a video on IGN?
Yep, looks like it's a video.

But it's auto-preloaded and playing even when not visible...

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

Unfortunately this kind of thought process is what leads to pages with megabytes of JS. Every byte matters.
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.

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

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.