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.
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.
No apology necessary. That was funny. Because it's true. :)
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 [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.