28 ms·
It's ironic that there's probably no bigger sales pitch for jQuery than this site. In every single example, the jQuery version is basically one or two lines of
by jamiesonbecker 6y ago
It's ironic that there's probably no bigger sales pitch for jQuery than this site.
In every single example, the jQuery version is basically one or two lines of code, versus 10-15 lines for the alternative. (and the jQ version seems significantly easier on the eyes as well.)
Also, jQuery supports promises and has for quite a while.
This page hasn't aged well. I've come full circle and am now using jQuery again.
- Zaheer 6y agoI generally agree but I think the site is specifically calling out use of jQuery in libraries to avoid a big dependency. "If you're developing a library on the other hand, please take a moment to consider if you actually need jQuery as a dependency"
- jamiesonbecker 6y agoAgreed! Especially for a smaller library or one that wouldn't adequately take advantage of jQuery shortcuts (or if you're using another library for DOM/shadow DOM, like react/angular/vue/etc) Counterpoint, if you're developing a library, then (based on this page itself), each line that would depend on jQuery would otherwise balloon to 15 times as large, so maybe the highly optimized jQ dependency would be worthwhile if the extra functionality would actually be useful (or perhaps "slim" jQuery). The savings would increase for each additional library that had a shared dependency on jQuery. But, anyway, developer time is valuable, and the 80kb or so for jQuery will probably be blown away as soon as you stick a single image on the page.
- jart 6y agoThis comment is a great example of what I call "lines of code mindset" which is form of tip of the iceberg mentality, where programmers optimize for simplicity only the code they see. Is saving 10-15 lines worth it if you need an 86.1 Kb vendor dependency? Hidden complexity you don't control is the most expensive kind I think.
- jamiesonbecker 6y ago> Hidden complexity you don't control is the most expensive kind I think. That's called encapsulation. :) Seriously, encapsulating complexity is the foundation of most programming paradigms.
- franklyt 6y agoActually, it's called abstraction, as a technical point.
- jamiesonbecker 6y agoGood point. This is what I was referring to: https://en.wikipedia.org/wiki/Encapsulation_(computer_programming) https://en.wikipedia.org/wiki/Encapsulation_(computer_progra...
- userbinator 6y agoIn the real world, it turns out that code you didn't write can also have bugs or not behave as you expect it to, so the less of that there is, the better. Encapsulation/abstraction should really be a tool of last resort. From experience, it doesn't actually help reduce complexity if overused, but just makes it hidden and more likely to surprise you when you're debugging.
- jamiesonbecker 6y ago> In the real world... From experience... Does jQuery (est. 2006) have more bugs in it than your code?
- scubbo 6y agoHave fun implementing everything from scratch in assembly.
- quattrofan 6y agoAs has been seen many times recently third party libraries are a major attack vector for the bad guys.
- eyelidlessness 6y agoI doubt the “choose not to use jQuery” path means “never write a function to wrap up that boilerplate”. The point is that you might be able to write the equivalent function instead of pulling down a whole library. That said, optimization techniques have gotten good enough that you might be able to just let a build tool do that for you. If you really still want to use jQuery.
- deleted 6y ago[deleted]
- graftak 6y agojQuery is immune to modern optimisation techniques such as three shaking (only including the modules actually used) because it’s fluent interface makes it a gorilla that holds quite a few bananas, even if you only need one of the bananas.
- ryanbrunner 6y agoI would imagine the percentage of front end projects that have a build chain sophisticated enough that tree shaking is important and where 30 KB has a significant impact on their bundle size is vanishingly small.
- WorldMaker 6y agoTree-shaking isn't a sophisticated feature with ES2015 modules and it's more surprising today when build chains don't support it. (The sophisticated features come into play doing any sort of tree-shaking on older module types such as CommonJS or UMD.) It's not even a build-chain only feature at this point. Some of the reasons the ES2015 module format was built the way that it was were exactly so that browsers can do their own tree-shaking of runtime code. Even if you don't save on the performance impact of the extra 30 KB from being downloaded, in modern enough browsers you would potentially still see a performance impact on browser memory usage and JIT compilation time. Even if your bundle size has bloated to a MB already, a 30 KB savings is still roughly a 3.3% savings. It's still noticeable. Whether that is "significant" is an argument of personal taste and how many "9s of performance" you try to deliver. Even single digit percentage savings can be huge "significant" wins for many projects.
- bichiliad 6y agoI think a lot of the initial appeal around jQuery was that it made querying and manipulating the DOM simple. Much of its features have been replaced by broadly-available APIs like Document.querySelector and Element.classList. Loading the entirety of jQuery just to access some of the remaining features just means you're loading JavaScript that you aren't going to use. I miss relying on jQuery because it's familiar and consistent, but it also makes it easy to forget how much better browsers have gotten in the time since it was introduced.
- cosmotic 6y agoI thought a big part of the initial sales pitch was not having to deal with cross-browser compatibility issues.
- deleted 6y ago[deleted]
- np_tedious 6y agoMaybe there was more than one big part!
- jrumbut 6y agodocument.querySelector was not available in IE 6 and 7. Dealing with those versions was where jQuery really earned its spot in the JS universe. It was a lot to remember where all the quirks were and the incantations to work around them.
- codeisawesome 6y agoIE 6. Now that's a name I haven't heard in a long time...
- martin_a 6y agoJust patched a problem in a WordPress site due to (now broken) support for IE7 two days ago. The elders of the Internet are still around. ;-)
- brundolf 6y agoWorth noting is that at least in the animation case, the non-jQuery (CSS) version should perform better than the jQuery version
- jamiesonbecker 6y agoAre you sure? AFAIR, jQuery has used native (hardware-accelerated) CSS transforms since 2014.
- brundolf 6y agoAt least in the example on this page, it performs .fadeOut() by changing the opacity via JavaScript instead of using the CSS transition property. You can verify by inspecting the DOM https://api.jquery.com/fadeOut/ https://api.jquery.com/fadeOut/ Edit: I just realized you said "transforms". Transforms are a separate question from transitions. CSS transforms are concerned with giving an element a different size, rotation, and/or position. Transitions are concerned with changing any given CSS property gradually over time (including potentially transforms). I think you're right that jQuery started using CSS transforms, but it does not appear to use CSS transitions.
- deleted 6y ago[deleted]
- jamiesonbecker 6y agoFair point. Thanks for bringing it up!
- brundolf 6y agoEdit: I partly misspoke. I assumed CSS transitions would be nontrivially more performant since it's a more declarative API and the math would be done natively by the browser, but according to MDN the performance difference is negligible in most (though not all) cases if you're using requestAnimationFrame in the JavaScript version: https://developer.mozilla.org/en-US/docs/Web/Performance/CSS_JavaScript_animation_performance#performance_comparison_transitions_vs._requestanimationframe https://developer.mozilla.org/en-US/docs/Web/Performance/CSS... The main case where CSS transitions are meaningfully faster appears to actually be transforms themselves, because for those the actual transition, too, can be moved to the GPU, whereas a JavaScript-driven transition still has to be run on the main CPU thread.
- nobleach 6y agojQuery, minified and Gzipped is 30.4kb. That's completely unacceptable for my needs. This is why folks complain about bloat.
- deleted 6y ago[deleted]
- jamiesonbecker 6y agoAre you being sarcastic? But, either way, it really depends. If you are writing a large application and jQuery saves thousands of lines of boilerplate, then it's totally worth it. For a tiny library (which is what this page is targeted at), then it's probably overkill and you should learn how to do it manually with pure JS. Both can be true at the same time.
- franklyt 6y agoHe might not be being sarcastic, servers are expensive and every little slice helps, though I think the cdn aspect changes this question somewhat.
- zhte415 6y agoMay or may not be. I deal with a not small amount of customers that are on extremely slow connections where 30k less makes a big difference. You can do a lot in 30k. jQuery makes life a heck of a lot easier though.
- ryanbrunner 6y agoI think this is a fair point if you genuinely want to keep your bundle size as small as possible. Many times, the people complaining about jQuery's size are serving 2 MB bundles. 30K is immaterial in that scenario.
- nobleach 6y agoLike I mentioned in another response, my bundle was 200k. 30k would have been significant bloat.
- jccalhoun 6y agoIt says you _might_ not need it not that you will _never_ need it. I have used the page when I'm trying to do something and would need jquery for one small thing. I don't want to use a library for one thing so 10-15 lines of code instead of all of jquery is a good tradeoff in those cases.
- franklyt 6y agoI haven't gone this far, but I still like lodash. It feels like it fleshes out a too-light core JS lib.
- deleted 6y ago[deleted]
- onion2k 6y agoI would prefer web developers accepted they need to write a few hundred lines of 'ugly' vanilla JS to drive their website than they include a 30KB library that they only really use 0.2KB of. On the web, user experience should really be a higher priority than developer experience.
- dylan604 6y agoif the 30KB library is already cached because everyone else is using it too, then isn't it technically smaller than however many hundreds of lines of code you had to custobuild?
- arp242 6y agoMost modern browsers don't really have global caches any more, and it's now all partitioned per-origin. I do agree 30k is hardly worth thinking about.
- satyrnein 6y agoI think they are referring to loading it from a global CDN.
- arp242 6y agoYes, those aren't cached globally any more. https://arstechnica.com/gadgets/2020/12/firefox-v85-will-improve-its-cache-partitioning-for-stronger-privacy/ https://arstechnica.com/gadgets/2020/12/firefox-v85-will-imp... https://developers.google.com/web/updates/2020/10/http-cache-partitioning https://developers.google.com/web/updates/2020/10/http-cache...
- satyrnein 6y agoThanks, I didn't know that!
- arp242 6y ago
- peanut_worm 6y agoThis is all very old javascript to be fair, the modern equivalents are as terse as jquery these days.
- jamiesonbecker 6y agoSomewhat true, but this was also old jQuery :) Even the old jQuery seems easier to read than the modern ES6 equivalent (IMO). jQuery: $(".classname").addClass("darktheme") ES6: document.querySelector(".classname").classList.add("darktheme")
- arp242 6y agoThere are quite a few more examples of this: $('.class').remove() $('.class').after(...) vs: var e = document.querySelector('.class') e.parentNode.removeChild(e) document.querySelector('.class').insertAdjacentElement('afterend', ...)
- jamiesonbecker 6y agoThis kind of code grows explosively in a moderately-sized project, and the sheer volume and verbosity makes it hard to debug. Not to mention requiring more tylenol ;)
- jarek-foksa 6y agoThe modern DOM equivalent would look almost the same as the jQuery version: document.querySelector(".class").remove(); document.querySelector(".class").after(...);
- realityking 6y agoThis is good example of how browser APIs have gotten better: // Edge 12 document.querySelector('.class').remove(); // Edge 17 document.querySelector('.class').after(...); Where jQuery shines - but also hides a lot of complexity- is when operating on an array of elements, e.g. if you want to remove all elements with a certain class.
- 6y ago
- domenicd 6y agoI agree this page hasn't aged well, but that's because it's stuck on IE10 as the support level it's targeting. If you don't need to target IE at all (only Edge), then everything becomes simpler. That's not always safe, but that's why you might not need jQuery... For reference: // JSON const data = await (await fetch('/my-url')).json(); // Post await fetch('/my-url', { method: 'POST', body: data }); // Request try { const resp = await fetch('/my-url'); // ... } catch (e) { // ... } // Fade In el.animate({ opacity: 1 }, 400); // Fade Out el.animate({ opacity: 0 }, 400); // Hide el.hidden = true; // Show el.hidden = false; // After target.after(el); // Append target.append(el); // Before target.before(el); // Each for (const el of document.querySelectorAll(selector)) { // ... } // Empty el.replaceChildren(); // or el.textContent = '', depending on which you find clearer // Filter [...document.querySelectorAll(selector)].filter(filterFn); // Get Height el.clientHeight; // Get Width el.clientWidth; // Matches el.matches('.my-class'); // Remove el.remove(); // Delegate document.addEventListener(eventName, e => { const match = e.target.closest(elementSelector); if (match) { handler.call(match, e); } }); // Trigger Custom el.dispatchEvent(new CustomEvent('my-event', { detail: { some: 'data' } })); // Trigger Native el.dispatchEvent(new Event('change')); // Extend Object.assign({}, objA, objB); // Parse HTML (new DOMParser()).parseFromString(htmlString); // Type obj[Symbol.toStringTag];
- jamiesonbecker 6y agoNice, thanks for this!
- mdtrooper 6y agoReally thanks, but Android Chromium has support "fetch" too late (2020). Well, I can wait.
- combatentropy 6y agoyoumightneedtoreadtheintro
- heleninboodler 6y ago> In every single example, the jQuery version is basically one or two lines of code, versus 10-15 lines for the alternative. "Every single example?" Are we reading the same page? I was fairly surprised to find that 75% of the alternatives are literally one-liners. There are a handful that swell up to 10-15 lines of code, but I would say it's a very small portion, far from "every single example."
- ratww 6y agoAlso, most of the more complex examples have single-liner equivalents in modern browsers. This page is just outdated. IE10 is a now deprecated browser whose last release was 4 years ago according to Wikipedia.
- franciscop 6y agoHave you considered some alternatives? I made a 3kb one back in the day (https://umbrellajs.com/ https://umbrellajs.com/) and there are others like Zepto that don't need to deal with the baggage of IE and old browser APIs and still give you the niceties of jQuery.
- skynet-9000 6y agoVery nice, and great site design too. (BTW, the baggage of supporting old versions of IE was removed when jQuery 2 was launched in 2013. There's now also a "slim" jQuery that removes a few features for a smaller file size.)
- franciscop 6y agoThanks! But jQuery has not really moved over, compare "addClass" in jQuery vs UmbrellaJS: - Umbrella 6 lines (max col 55): https://github.com/franciscop/umbrella/blob/master/src/plugins/addclass/addclass.js https://github.com/franciscop/umbrella/blob/master/src/plugi... - jQuery 35 lines (max col 83): https://github.com/jquery/jquery/blob/master/src/attributes/classes.js#L22-L57 https://github.com/jquery/jquery/blob/master/src/attributes/... Yes I reuse methods there to make my life easier like `.eacharg()`, but jQuery as well with `getClass()`. The difference is that UmbrellaJS is using the native `classList.add`, while jQuery is doing string concatenation and cleaning it up heavily. jQuery does not even use `className`, it uses the even older `.setAttribute()`. Why they cannot just move over? I did try to move them over, the thing is that the edge cases of jQuery were solidified into features as people found them and wrote tests. And jQuery is very big on not breaking behaviour even for small things, so the only way to maintain the current exact behaviour is to have the current exact code, hence you cannot just migrate it over.
- deleted 6y ago[deleted]
- jamiesonbecker 6y ago> jQuery is very big on not breaking behaviour even for small things You answered your own question :)
- galaxyLogic 6y ago> In every single example, the jQuery version is basically one or two lines of code, versus 10-15 lines for the alternative But isn't the point here that you can wrap the 10-15 lines into your own function which you can then call with just a single line of code? So you "might not need JQuery" because you can program it yourself following the examples given, and can choose which parts of it you need and want to package with your app.
- catmanjan 6y agoI've done this before - you just end up rewriting jQuery hehe.
- DarkWiiPlayer 6y agoYou'd end up writing a subset of jQuery that only has the parts you need and skips those where you almost wouldn't gain anything.
- 3131s 6y agoWell, except that jQuery and a number of third parties have already extracted or ported various subsets of jQuery and have packaged it already for easy integration.
- galaxyLogic 6y agoThat's a good solution if you need such a subset. But maybe you need just a single function. And maybe such a single function is currently already provided by the browser APIs. Or maybe there are packages of individual functions of JQuery? But that would serve little purpose IF the functionality is provided by current browsers. In any case I think the article serves a good purpose in explaining what are the most useful parts of JQuery and how you could implement them yourself with the more modern browsers if and when you need them. My preference is to avoid dependencies if I can and prefer depending on my own code which uses standard APIs if possible.
- 6y ago
- pkorzeniewski 6y agoI've never stopped using jQuery, it makes everything so much easier to work with. I've built large web apps using only jQuery and never had any problems, I just really like direct DOM manipulation instead of some abstractions and jQuery makes it as simple as possible.
- princevegeta89 6y agoAgree with this. Fancy libraries like React/Vue etc are great, but they require more human resources in terms of development and add more complexity to your development cycles. I am working on a side project and initially got tempted to use Vue for the front-end but once I stepped back and re-thought about it, jQuery was a no-brainer in terms of how much I can achieve in the time I have.
- cogman10 6y agoWhy do jQuery at all now? IE 11 is no longer supported. All major browsers are evergreen and, except for some small edge cases that jQuery didn't really support anyways, they are pretty much completely unified in the APIs they support. If you are really worried about that 1% difference, then you can use tools like babel to cover those cases. The only reason to reach for jQuery, IMO, is familiarity. If you don't want a framework, then just write vanilla js.
- slmjkdbtl 6y agoagree, i think this page has a lot of value in explaining how jquery works which is very valuable for beginners, need a more accurate title i guess
- HiJon89 6y agoI think this misses the point, which is called out directly at the top of the site: "jQuery and its cousins are great, and by all means use them if it makes it easier to develop your application. If you're developing a library on the other hand, please take a moment to consider if you actually need jQuery as a dependency." If you're shipping a big application and need to use a large number of these utilities, by all means use jQuery. But if you're shipping a small library and only need one or two of these functions, you might want to forgo the dependency. Using jQuery in your library forces it as a dependency onto everyone who uses your library, potentially making them deal with version conflicts if your version of jQuery doesn't align with their version of jQuery (or the version that another dependency wants).