I loved jQuery, and still do (2019) • Hacker News Board

Re: I loved jQuery, and still do (2019)

#111

Post by romellem » Tue, Jun 29, 2021, 6:17 PM UTC

chrismorgan wrote: post #85

rchaud wrote: post #61

Every time anything about jQuery is posted, someone will inevitably post the "You might not need jQuery" site. [0] 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…

That site is generally aiming at providing exact replacements, and quite a few of its examples are not great for various reasons: 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 wh…

Why is removing the first element repeatedly O(N^2) while removing the last one O(N)? Is it because its cheaper for the browser to remove things from the end of a NodeList rather than the front? (similar to how .pop() is cheaper than .shift() for larger arrays?)

Re: I loved jQuery, and still do (2019)

#112

Post by oatmealsnap » Tue, Jun 29, 2021, 6:17 PM UTC

rchaud wrote: post #95

gred wrote: post #79

Earlier quoted context omitted.

I can see where you're coming from, but just wanted to add a counterpoint. 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…

In your example, switching from jQuery was just a matter of personal preference. There's nothing wrong with that. 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 sho…

That's not how I see jQuery hate.

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.

Re: I loved jQuery, and still do (2019)

#113

Post by legitster » Tue, Jun 29, 2021, 6:21 PM UTC

klysm wrote: post #102

legitster wrote: post #18

I love jQuery. I can just drop in the library onto any existing webpage, and have almost complete control of the DOM with just a few lines of code. And the built in actions and animations are all so simple and perfect for the web. And the structure and naming is so good that I rarely need to look up any references anymore. I get that browser support isn't as important as it used to be, but it is nice to know that you…

I don’t know how universally true this is, but I find that the easier it is to write the first time, the harder it is to maintain. For example, it’s really easy to write a python script but it’s harder to change. It’s harder to use types on a program the first time but it’s easier to change. I think that’s the core of the issue here with peoples negative feelings about jQuery. Sure it’s super easy to make the page do…

I'm not sure if that's true. I find jQuery much easier to maintain than vanilla or even some modern JS libraries.

> $("#button").on('click', function(){ > $(".modal").slideUp(); > });

Obviously a simple example, but this is really easy to understand - even for a non-programmer! The equivalent vanilla JS to do this is honestly pretty nasty in comparison.

The only problems I have seen when maintaining jQuery is when someone wants to drop in a bunch of custom functions they have designed in vanilla JS - or try to treat it as a replacement for a front-end framework.

But for it's intended purpose of adding interactivity into HTML content, I think it is still the king.

Re: I loved jQuery, and still do (2019)

#114

Post by shkkmo » Tue, Jun 29, 2021, 6:27 PM UTC

rchaud wrote: post #95

gred wrote: post #79

Earlier quoted context omitted.

I can see where you're coming from, but just wanted to add a counterpoint. 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…

In your example, switching from jQuery was just a matter of personal preference. There's nothing wrong with that. 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 sho…

> it's implied that you shouldn't call yourself a dev if you use jQuery and not vanilla JS.

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...

Re: I loved jQuery, and still do (2019)

#115

Post by FinalBriefing » Tue, Jun 29, 2021, 6:27 PM UTC

rchaud wrote: post #61

Every time anything about jQuery is posted, someone will inevitably post the "You might not need jQuery" site. [0] 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…

I think that websites needs an update, too. It would be a bit more convincing if they didn't try to support IE, and explained why the native methods are better.

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.

Re: I loved jQuery, and still do (2019)

#116

Post by gmiller123456 » Tue, Jun 29, 2021, 6:29 PM UTC

acabal wrote: post #45

I still use jQuery even for new projects. Yes, these days it's possible to do everything jQuery does using native JS, but I find the native version to be much more verbose and its naming conventions to be far less clear. For example, natively getting a list of children is `el.children` but natively getting the parent is `el.parentNode`, not `el.parent`. Meanwhile, natively getting a list of classes is `el.classList`,…

> but natively is the mouthful of `document.querySelectorAll('selector')`

I'm curious as to whether there's a proper use case for querySelectorAll. I always use the getElementsByClassName, getElementById, and getElementsByTagName based on what I want. I find the more general querySelectorAll to be too likely to produce a bug when someone uses a CSS class name that equals a tag or ID. You can make it work, but I find it's too easy to re-use a word in different context, especially if it's different people doing the coding vs CSS.

Re: I loved jQuery, and still do (2019)

#117

Post by chrismorgan » Tue, Jun 29, 2021, 6:35 PM UTC

romellem wrote: post #111

chrismorgan wrote: post #85

Earlier quoted context omitted.

That site is generally aiming at providing exact replacements, and quite a few of its examples are not great for various reasons: 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 wh…

Why is removing the first element repeatedly O(N^2) while removing the last one O(N)? Is it because its cheaper for the browser to remove things from the end of a NodeList rather than the front? (similar to how .pop() is cheaper than .shift() for larger arrays?)

On reflection, “many” wasn’t the best word to use; “some” would be better.

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.

Re: I loved jQuery, and still do (2019)

#118

Post by chrismorgan » Tue, Jun 29, 2021, 6:37 PM UTC

johannes1234321 wrote: post #93

chrismorgan wrote: post #85

Earlier quoted context omitted.

That site is generally aiming at providing exact replacements, and quite a few of its examples are not great for various reasons: 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 wh…

> 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`); const data = await fetch('/my/url').then(r => r.json());

Hmm, forgot about that style. Where you only have prefix await, .then() can end up nicer (though I might split it into `const response = await fetch('/my/url'); const data = await response.json();` as yet another style), but if you can have suffix await, I reckon it’s much nicer. Goes well with fluent API styles.

Re: I loved jQuery, and still do (2019)

#119

Post by LukeBMM » Tue, Jun 29, 2021, 6:37 PM UTC

mbostleman wrote: post #106

> Then GMail came in 2004 OWA and Ajax appeared 6 years earlier. Why would Gmail be considered the milestone instead?

While the tools were available earlier, I think it's fair to say that GMail was most folks' first experience with a functional (while the content of the emails was still present, the point of GMail was reading and managing emails, rather than displaying their content) web app, rather than an informational one.

It seems a valid milestone, if not the first example.

Re: I loved jQuery, and still do (2019)

#120

Post by FinalBriefing » Tue, Jun 29, 2021, 6:39 PM UTC

rchaud wrote: post #101

ThePadawan wrote: post #72

Earlier quoted context omitted.

I agree that the vanilla JS snippets seem hilariously more complicated, but simplicity isn't everything. 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.

If it's a corporate environment, the standards are different, understandably. But the hostility to jQuery is also primarily concentrated among corporate devs that seemingly cannot imagine that jQuery might be valuable for use cases other than their own. 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…

> little bit of a facelift

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.