That's 30KB over the network and 90KB of JS code in memory so that you don't need to learn about 5 standardized browser API methods that are the same in every browser going back to IE9 then. No doubt that gives you a better developer experience but I don't think your users are thanking you.
The internets users managed to live with this terrible 30k burden in the late 2000's when it was the only choice. I think probably in 2021 when 30kb is a rounding error on page sizes they can also probably manage it.
Bingo. 30kb doesn't seem like much, but its easy to think it doesn't matter when viewing one dependency in isolation. But if you say "it's just x kb" to all dependencies, then you have a problem when they're all aggregated.
This is why I appreciate Svelte's take: with a compiler-heavy approach, you can have a great dev experience without saddling your users with extra dependencies.
Since many people seem to be religious today about which "packer" is the best and that using one in the first place is a necessity, the answer is apparently "yes".
> That's 30KB over the network and 90KB of JS code in memory
A fair point, but compared to the payload of most sites (let alone apps) these days that is chicken feed.
Just opened that page itself and DevTools tells me 5.2Mb was transferred including ~175KB of JS from twitter, 65Kb JS for the video player (which seems to have 46Kb worth of css associated with it!), ~1Mb worth of font resource, ...
> so that you don't need to learn about 5 standardized browser API methods
That and the way jQuery does method chaining, which a lot of people find far more convenient, but other features. jQuery does a lot more than querySelector/querySelectorAll/friends.
> No doubt that gives you a better developer experience*
<attenborough>And here we see a forum commenter in its natural habitat, hunting the point. It sidles up slowly, and pounces...</attenborough>
(with apologies for failing to resist being facetious and slightly dickish there)
>* but I don't think your users are thanking you.*
I don't think most users will notice. Those that do due to slow connections, metered connections, low-power/low-memory devices, etc, are going to baulk at much more before even noticing jQuery on this site.
On something like HN (23.8K transferred for this page before my comment was added) 30Kb might look chunky, but few sites are remotely close to being as lean as HN.
I'm not happy about it, but the reality is that 120kB is small potatoes in the modern web world. Would it be better without, sure? But there are bigger fish to fry. If jQuery helps the developer achieve their design and development goals, that will play out better for the end-user. It's not ideal, but it's realistic.
If jQuery helps the developer achieve their design and development goals, that will play out better for the end-user.
That's not the dilemma though. Developer can build solutions without jQuery. They'll be faster, smaller, and have fewer dependencies.
Plus, if you're only using jQuery for DOM and events then it probably isn't helping you. Those are two areas where writing vanilla JS is can often be easier than writing the jQuery code to do the same job.
jQuery versus vanilla DOM is slower, larger, and adds dependencies.
jQuery versus [framework of the month] is "faster, smaller, and [has] fewer dependencies". Simpler build, too, while still keeping you from having to worry about which browser supports what.
Depends on what the most likely alternative is, then.
There are plenty of modern frameworks that are smaller than jQuery (svelte, Preact, etc). In some apps they may also be faster. If you pick svelte there's the same number of dependencies.
I don’t follow. Is the implication here that users can identify an experience difference cause by a 30KB over-the-wire asset, or more, a 90KB in memory one? I know I certainly wouldn’t claim to have that ability myself even on low quality networks.
In that case, most of the web is unusable nowadays, and jQuery is not your main problem. Maybe your argument is valid in less-developed countries where more people have spotty connections and more websites have adapted to that (but I wouldn't know, sorry).
