It's supposed to be making a case against jQuery if you're pulling in the whole library just to do this one thing.
I've always read the site as "here's how to do it in native JS, yes it's uglier, but if you only need this, you can skip pulling in another dependency."
Over-engineering websites has been around forever. That's partially why jQuery is modular, letting you pick what you need.This covers the 'use jquery for just this one thing' crowd. And if they're lazy, well, they can hang their heads in shame because they have added an entire 83 KB to the page's initial load time. /s
(unless the browser has a CDN cache stored, in which case it wouldn't impact load time at all)
I recently removed jQuery from a website, and the YMNNJQ website was one of the bits of info that gave me the nudge to do that. The website in question only used jQuery in a handful of places, it was one of the few third party libraries being used (so the % size savings was significant), and I'm fairly fluent with JS... The website simply hadn't gone through a major update in the past 5 or 6 years, and the browser landscape has shifted enough in that time that the pros/cons weigh differently now.
So I think there are scenarios where this info is sometimes useful in the "I might remove jQuery" sense, and not in the "wow, I'm definitely keeping jQuery!" sense.
My original comment left out some context: on HN, a lot of the hostility to jQuery is either cultural or gatekeeping oriented. Cultural opposition is of the 'not invented here' variety, e.g. 'Why use Dropbox when you could do this w/ rsync? Gatekeeping-related opposition is where it's implied that you shouldn't call yourself a dev if you use jQuery and not vanilla JS.
That is the kind of discussion that happens nearly every time a link to YMNNJQ is dropped.
jQuery promotes bad development patterns, AND brings a cost for end users. Developers will do themselves and futures devs a favor by not choosing to use it. Is it really gatekeeping to expect people to be aware of commonly used 10 year old features?
I assume developers who share YMNNJQ are just sick of inheriting messy projects built with jQuery. I know I am.
Part of my screening process is making sure something like that doesn't fall in my lap again. Even static sites aren't safe these days.
If you do web development as a job, it's your responsibility to stay up to date on what best practices are. With EC2015 being several years ago now, jQuery wouldn't be a learner's starting point today.
Those that developed bad habits during jQuery's heyday a decade ago may still be writing bad code. And it's someone else's job to clean that up. That's the circle of life, and it's hardly exclusive to jQuery users.
I've never seen that. The closest I've come to seeing that is that comments that imply that using jQuery indicates lower levels of experience as a developer.
> Cultural opposition is of the 'not invented here' variety, e.g. 'Why use Dropbox when you could do this w/ rsync?
How is that "not invented here"? That seems more like a preference for open source software.
I looked at submission history and I don't really see either of those attitudes prevalent in a quick scan of the comments:
https://news.ycombinator.com/from?site=youmightnotneedjquery...
Some use a bad technique; e.g. “Empty” removes the first child repeatedly, which is O(n²) in many environments, rather than removing the last child repeatedly, which is O(n), or `el.innerHTML = ""` which is shorter and more efficient in general)
Some suffer because they’re supporting IE which no one should do any more (fite me); e.g. “JSON” is long because it’s using XMLHttpRequest, but the Fetch API would make it vastly shorter (`data = await (await fetch('/my/url')).json()`—as an aside, suffix await like Rust settled on is so much nicer: `data = fetch('/my/url').await.json().await`); and “Each” should use `document.querySelectorAll(selector).forEach((el, i) => …)`; and “Matches Selector” is just `el.matches('.my-class')` now.
Also some look bad because jQuery optimised an operation that isn’t terribly common or should generally not be done, such as most of the width/height things (most uses of measuring element dimensions in JS are unnecessary, bad or wrong; aim to use CSS most of the time), “Index” (needing to know that an element is the nth child element is decidedly esoteric), “Type” (if you use this, you’re almost certainly doing the wrong thing), and “Parse HTML” (picture me running away, screaming in horror; this method is practically a primed security grenade). And remember, jQuery having optimised these things means you’re paying to ship that stuff that you’re not using.
And finally some seem more complex because they’re matching some unnecessary jQuery complexity, e.g. in “Set Height” (and alike in “Set Width”), $(el).height(…) takes a string, a number, or a function that returns a string or a number—but you’d be wiser to write `el.style.height = string;` or `el.style.height = number + 'px';` rather than being unnecessarily flexible.
Most people that use jQuery use a tiny subset of its functionality. The site is about showing that most uses of jQuery could actually dispense with it at little cost, if they’re the sort that value performance and such and want to ship less unnecessary code.
const data = await fetch('/my/url').then(r => r.json());
Mind that in this example the then is a little nicer only by chance that the continuation is quite trivial. If you'd need something more complex than the single function call it is annoying and if you do any later change to this code, you likely have to change this as well.
I typically go to the multiple lines, but wanted to show that there is a kind-off suffix await.
I am not used to suffix await, as i like to spot the places where i jump out of the coroutine easily. But maybe that would change if I'd use languages with suffix await more :)
In the past, I believe that most or all browser implementations used array-like structures to do various things like this, and so removing the first element entailed shifting all the remaining elements, whereas popping from the end doesn’t require shifting any elements.
More recently, I believe that most or all browser implementations have shifted to linked-list-like structures, with bad patterns like this being a cited reason. (I don’t know the full story by any means, but I’m inclined to be disappointed by the switch, because for most access patterns arrays aren’t a problem at all, and use less memory, sometimes even being a smidgeon faster. But although I suspect they’d have better typical performance and certainly better memory size, they have vastly worse worst-case performance, being approximately O(n) instead of O(1) for some operations.)
Remember also when talking of NodeList like this that it’s a type for JavaScript to consume; what browsers use internally for representing their DOM is an implementation detail. A leaky one, certainly, in performance details like this and types like HTMLCollection and NodeList (especially live NodeLists), but an implementation detail nonetheless.
In a corporate environment, if "I need to include jQuery as a dependency" involves asking another team how to set up custom deployment or whatever, and that is the difference of days between deploying a feature or not, then I'll definitely take the hit of 10 more SLoC vanilla JS.
Not every site out there is an database-driven SPA that needs QA review and a deployment pipeline each time an update is made. Lots of sites are just simple WordPress or even raw HTML pages that need a little bit of a facelift, with animations or transition. jQuery does the trick, and as a bonus, it's a much gateway drug to JS than the official ES6 documentation could ever be.
Proceeds to download 30kb (compressed) swiss army knife of a library when just a toothpick would do.
jQuery is about as much of a gateway to ES6 as pot is to heroin. Devs who still use jQuery have had 10+ years to learn `document/element.querySelectorAll()`. Longer for event listeners.
> Devs who still use jQuery have had 10+ years to learn
Or possibly we learned it in 9 years 11 months ago and still think jQuery was a more elegant solution.
I agree that 30kb can be big, especially since it's JS that needs to be executed, but on the other hand if the toothpick means you save a minute, you can use it to optimize an image and end up with a lighter and faster website.
I write random bits of scripts for internal use, I'm happy enough to drop the min.js in with my index.js, index.css and index.php files, especially if it means I can continue to use
getJSON('/my/url', function(data) {
});
var request = new XMLHttpRequest();
request.open('GET', '/my/url', true);
request.onload = function() {
if (this.status >= 200 && this.status < 400) {
// Success!
var data = JSON.parse(this.response);
} else {
// We reached our target server, but it returned an error
}
};
request.onerror = function() {
// There was a connection error of some sort
};
request.send();
I've just looked at one page I wrote which has a little jquery in it. The outputted data is 673kb, which takes nearly half a second to generate and load. The jquery file being static is down in 0.01s.
This isn't a problem
Starting with the Ajax exmaple isn't the best way to get people on board, either. Until the Fetch API was widely adopted, I also reached for a library if I had more than one very simple API call.
I look at that site and laugh. Is this supposed to be making the case ~against~ jQuery? Maybe the audience for that site are seasoned developers for whom the vanilla JS syntax is easily understood. Everybody else is going to look at those code snippets and think jQ is the way to go.
For people that have struggled through HTML and CSS, there is perhaps nothing more deflating than to realize that even basic UI interactivity requires JS. But with jQuery the code snippets needed are short and understandable. Vanilla JS in comparison looks like an entirely different language.
[0] http://youmightnotneedjquery.com/