Live data from Hacker News

Why I'm still using jQuery

arp242.net

31–40 of 246 posts

Re: Why I'm still using jQuery

#32
This is all fine and dandy; use what works for you. However, as many of us have learned when trying to aggressively optimize performance, execution time is generally much longer for jQuery than with vanilla JS. So if you're after high PageSpeed scores, for example, jQuery is the damn devil (or at least one of them).

Re: Why I'm still using jQuery

#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 thought using one of the modern js frameworks for it is a good idea" pages I feel years older. Instead of showing me text using html they pack that text in js on the server (it usually exists in an html compatible form already), then they shove that JS down the connection, then my browser has to interpret the JS, so it can get the html, which it then has to interpret too. And then, finally, I see my text.

And because all of this is so slow we get techniques like "server-side rendering". The first time I read about server-side rendering I didn't understand what it was: so, you produce the html on the server. And send it to the client. Yes ..? What is the new part? Why is this something that people present as the next savior of the web?

This is some special kind of madness and I wonder when it will stop.

Re: Why I'm still using jQuery

#34
post #22

Earlier quoted context omitted.

> If you need state management, build a very complex app, etc. ... don't. I'm not so sure you do for many sites. Take something like Reddit for example; I don't think the new SPA redesign is any better than the old template-driven app. In fact, IMHO it's worse in every way. Part of that is just a matter of design and not technical, but part of it is just "SPA hell": CPU goes to 100% on load, takes ages to load stuff,…

SPA is by million times better than "classic template-driven" trash. I don't just "think" so, I have 7 years of experience with "classic templates" and 8 years with SPA.

Anyone can throw out a better-because-of-experience answer, and in fact I’ll do so now: I also have 15 years of experience in front-end dev and I disagree with your premise. It completely depends on what you’re trying to build, and SPAs are too heavily used at the light-interactivity end of the scale. We’re failing our users with brittle solutions that make us feel cleverer as developers.

Re: Why I'm still using jQuery

#36
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

Re: Why I'm still using jQuery

#37
post #29

Sure. But as always. It depends. If you're writing a highly interactive app and your jQuery script starts containing a lot of view state, eventually you'll go mad and probably duplicate a lot of logic on server and client too. Seeing your app as a function of a data structure/state is then much simpler. Although it will require a bit more thought initially. App = f(s). Again, it depends. If you're writing static site…

The most enjoyable front end development experience I’ve had is jQuery + HandlebarsJS.

Re: Why I'm still using jQuery

#38
I’d be curious to see how many people have a cached copy of jQuery from one of the popular CDNs and what the overall real world effects are of that.

(That got me thinking of another potentially interesting analysis/discussion about the distribution of jQuery versions being used…)

Re: Why I'm still using jQuery

#39
post #22

Earlier quoted context omitted.

> If you need state management, build a very complex app, etc. ... don't. I'm not so sure you do for many sites. Take something like Reddit for example; I don't think the new SPA redesign is any better than the old template-driven app. In fact, IMHO it's worse in every way. Part of that is just a matter of design and not technical, but part of it is just "SPA hell": CPU goes to 100% on load, takes ages to load stuff,…

SPA is by million times better than "classic template-driven" trash. I don't just "think" so, I have 7 years of experience with "classic templates" and 8 years with SPA.

Cool story.

So, why?

Re: Why I'm still using jQuery

#40
The given example of element.nextSibling is a great example of what jQuery gets wrong. In jQuery, that's going to be $(el).next();

On first encountering $(el).next(), you need to answer a bunch of questions. Next what? Why is this a function and not a property of the object? Why not call it getNextSibling? What the hell is $() doing?

element.nextSibling is very clear. It's the next sibling of the element. It's idiomatic javascript, and it follows a good naming convention, which is a skill that is language agnostic.

The author is also conflating their time learning as a pro for jQuery. Had they learned vanilla javascript first, their point about not knowing which nextSibling to use would be moot. What they are referring to here is an idiosyncrasy, and jQuery is jam packed with them. The difference is they have learned them already.

If you learn jQuery today, you're not learning core JavaScript, and considering the trajectory of web technologies you'll be doing yourself a disservice not to use that learning time on actual JavaScript that you could use in future tools. jQuery isn't a bad choice if you know it already, but if you are a new developer do yourself a favor and learn the foundation it's built on first.

Post reply on HN