Live data from Hacker News

Why I'm still using jQuery

arp242.net

101–110 of 246 posts

Re: Why I'm still using jQuery

#101

As someone who does application security assessments for a living, the biggest problem with jQuery is the lingering, outdated, vulnerable versions that are pervasive (1.x and 2.x in particular) in so many applications. I don't care if you decide to use jQuery or not, just have a plan to maintain it and be able to update it without breaking everything, should the need arise. /preaching

Just curious what vulns specifically you're referring to?

Re: Why I'm still using jQuery

#102
post #28

I'm heavily inclined to agree with this. In fact, only this weekend I was working on a very simple one page tool and from the get-go I decided to adopt this "vanilla" only approach, i.e no JS libraries really at all. Pretty quickly I found myself wishing I had just used jQuery or at least some other library to make stuff easier and get things done faster. When I finally got it completed in the end I wasn't sure why I…

So what was the struggle with vanilla js? I'm just curious :) One of the first things I learned in web development was jquery but right now I never use it. Even if I create a vanilla html/css/js website.

The fetch API is nowhere as convenient as the jQuery one.

It requires craft to get addEventListener() on par with on().

jQuery comes with many implicits loops that save you time.

fadeIn() is easier to handle than the equivalent css. jQuery supports edge if you target it (things like prepend(), parent() work on it).

Error handling is just better. E.G: jQuery().val() will not raise an error if there is no match while document.getElementById().value will.

And probably a hundred of other little details that won't come out of my head but that will grind my gear if I start working on code.

Chaining is awesome to manipulate DOM. The imperative API is very verbose.

So. Many. Plugins.

I'm more of a VueJS guy now, but if I have only a quick page to setup, the 30ko of jquery are better than anything I can produce to wrap my repetitive code.

Re: Why I'm still using jQuery

#103
post #99
post #33

> In my experience server-side generated templates lightly sprinkled with “progressive enhancement”-style JavaScript are still the best way to do that. Those apps are easier to develop, tend to be faster, tend to have fewer bugs, and your laptop’s fan won’t wake the neighbours. Thanks for that part. Really. A heartfelt thank you. Every time I see another "hey, I only want to show you text, but for some reason I thoug…

This is some special kind of madness and I wonder when it will stop. There's light at the end of this tunnel in the form of compilers like Svelte or Stencil.js replacing frameworks. The improvement here is that since there's no special runtime the bundles are very small, so there isn't a lot of JS to parse. Also the code you have to write is much shorter comparing to frameworks.

> There's light at the end of this tunnel in the form of compilers like Svelte or Stencil.js replacing frameworks.

I am a bit skeptical that adding more complexity to something that's already much more complex than it should can be a solution.

Re: Why I'm still using jQuery

#104

Earlier quoted context omitted.

I have no claims that SPAs are better end-user experiences out of the box. Your quote is about how easy it is to develop and maintain an SPA, not how good users have it after the fact (which entirely depends on how good your team is at building the app). I'm starting to think I need to clarify that paragraph :/

Probably - "Has it occurred* to you you might simply not understand the advantages of this approach?" makes you sound pretty dismissive of the parent comment's points. Also - as someone who disagrees with you I don't see any compelling points in things like: > "So when the author says that classic HTML with sprinkled js on top is "easier to develop", I smirk. If it were, developers would not be flocking en masse towa…

I think there's a canyon between outright calling an approach "madness" and simply… understanding its advantages, yes.

Performance is a concern, and that's one of the main reasons why serverside rendering is being adopted as a technique. So when OP berates the existance of SSR, I have to wonder if they understand the larger picture. If it's rude for me to point this out, I apologize for being rude; my point still stands, though.

I don't think the SPA approach is the end-all-be-all but I'm definitely happy to have adopted it for my current project (a mid-size web app mixing classic list views and a few more complex bits and pieces here and there). Had I done it with jQuery, I'd still be building it; and had I done it in my classic hybrid approach, I would not have as many options as I currently do when building new pages/views.

Re: Why I'm still using jQuery

#105
Idk in regards of how better the code can be structured with React or Vue, but opening apps based in these frameworks makes similar effect to starting Monero miner locally.

Re: Why I'm still using jQuery

#106

As someone who does application security assessments for a living, the biggest problem with jQuery is the lingering, outdated, vulnerable versions that are pervasive (1.x and 2.x in particular) in so many applications. I don't care if you decide to use jQuery or not, just have a plan to maintain it and be able to update it without breaking everything, should the need arise. /preaching

I'm curious - what are the types of vulnerabilities that lie in the client-side jQuery?

Re: Why I'm still using jQuery

#107
post #68

Earlier quoted context omitted.

> Has it occured to you you might simply not understand the advantages of this approach? I find it pretty rude to use the "you don't like it because you don't understand it" argument. I build SPAs at work, I know their benefits, and I still believe that they're more difficult to develop than adding JS on top of classic HTML (not saying they're worse, but certainly I don't find them easier). > So when the author says…

> I still believe that they're more difficult to develop than adding JS on top of classic HTML (not saying they're worse, but certainly I don't find them easier). You're right, I should have been clearer. Emphasis on develop and maintain . If you're just building a near-static site with, say, some slideshow that needs basic JS then I'd use jQuery too. I'm sure there's a bazillion plugins that already do what I want a…

> You're right, I should have been clearer. Emphasis on develop and maintain.

Did you ever think that you might want to put the user experience first?

Look at YouTube with their great SPA. If I'm on mobile and not using a flagship phone with 3gb of ram, it's just great: I scroll through my search results which are these idiotic incrementally loading page, then I select a video, watch it and want to go back. Surprise! I see the loading spinner again an my scroll position is lost. State seems so broken with SPAs that it only ever works in some demo apps that were solely built to prove that you can have SPAs with a working back button. Great, I already had that on YouTube in 2006 with a fancy and handy feature called pagination for the search results.

But I guess once we kill Firefox this will become much better since Google will just do whatever the duck they want with the web.

Re: Why I'm still using jQuery

#108
post #68

Earlier quoted context omitted.

Has it occured to you you might simply not understand the advantages of this approach? There's a lot of crazy things in the world. Talk to a child about the economy or country borders and you'll realize how some things are just not straightforward to explain the advantages of. Serverside rendering in JS is no different to SSR in classic frameworks. You generate HTML serverside. Except in this case, you do it using Ja…

> Has it occured to you you might simply not understand the advantages of this approach? I find it pretty rude to use the "you don't like it because you don't understand it" argument. I build SPAs at work, I know their benefits, and I still believe that they're more difficult to develop than adding JS on top of classic HTML (not saying they're worse, but certainly I don't find them easier). > So when the author says…

> I'd say that we, developers, often move to overcomplicated and difficult tools/approaches.

Smart people with simple problems, we get bored, I guess. There's a lot of boring work out there.

I agree though, I went from Angular to ASP.NET back to React, and server side despite being less 'flashy' was much more productive with less effort.

Re: Why I'm still using jQuery

#109
post #68

Earlier quoted context omitted.

> Has it occured to you you might simply not understand the advantages of this approach? I find it pretty rude to use the "you don't like it because you don't understand it" argument. I build SPAs at work, I know their benefits, and I still believe that they're more difficult to develop than adding JS on top of classic HTML (not saying they're worse, but certainly I don't find them easier). > So when the author says…

> I still believe that they're more difficult to develop than adding JS on top of classic HTML (not saying they're worse, but certainly I don't find them easier). You're right, I should have been clearer. Emphasis on develop and maintain . If you're just building a near-static site with, say, some slideshow that needs basic JS then I'd use jQuery too. I'm sure there's a bazillion plugins that already do what I want a…

Funny that a mere two mo ths ago, when I posted this, many on HN begged to differ:

https://news.ycombinator.com/item?id=19534060

Post reply on HN