4 ms·
It's a much nicer syntax and has a ton of useful helpers. Vanilla js for similar things just looks like someone has waved the ugly stick at it. There are soun
by andybak 4y ago
It's a much nicer syntax and has a ton of useful helpers.
Vanilla js for similar things just looks like someone has waved the ugly stick at it.
There are sound arguments against jQuery but the "you can just use vanilla" is the least convincing.
- jaywalk 4y agoNot 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 agoOP's argument is that jQuery is all you need for basic use cases, so that'd be the only JS library loaded.
- kijin 4y agoExcept 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 agoA 10% performance gain is quite a big deal, I wouldn't just shove it under the table like that.
- Dudeman112 4y agoLike 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 agoYes. 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 agoTo 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 ago30kb 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 ago30kb gzipped is still 10x larger than Preact for reference
- SemanticStrengh 4y agothat doesn't make it an issue in any way, it's not a numbers competition unless you have a 56K
- Smaug123 4y agoOne 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 agoor use https://axios-http.com/ https://axios-http.com/ for ajax stuff
- dgb23 4y agoIt 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 agoThis 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.