Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I'm still using jQuery

arp242.net

Post reply on HN
Print view View original

221–230 of 246 posts

Re: Why I'm still using jQuery

#221

Post by [deleted] »

andrei_says_ wrote: post #218
candu wrote: post #125

Earlier quoted context omitted.

This is the part that often gets forgotten in these discussions: it shouldn't be "SPA for everything" vs. "vanilla HTML / CSS / JS for everything"; rather, we should be using the most appropriate set of tools for the job. I've worked on simple static sites, for which I typically lean more on vanilla HTML / CSS with a sprinkling of JS as recommended here. I've also worked on heavy-lifting applications, for which the l…

AT&T’s website account pages only serve static html. But they are rendered by js and I have to wait looking at a loader after every click. Why is that? Why do so many static websites and blogs use SPA technology for all their pages? It can’t be that it’s just to make me mad (although it works). Are people insane? How does spending 10x the $ and effort for a worse result make sense?

[deleted]

Re: Why I'm still using jQuery

#222

Post by pier25 »

noir_lord wrote: post #216
pier25 wrote: post #143

To give you an idea where I come from... I started doing front end in the late 90s, and for the past 5 or so years I've been mostly doing SPAs with Vue, React, Inferno, and Angular. I'm done with SPAs and the whole modern front end workflow. If there was a solid benefit to a SPA it would make sense to endure all the complex development, ever changing ecosystem, etc, but in the vast majority of cases there is no benef…

Vue gets that part pretty right at least, they work hard not to break things unnecessarily across versions and never in version (in my experience). Nothing like jQuery's track record but they don't have the history yet to call on.

Yeah, you can still use the component object notation in Vue 2.

AFAIK they will keep that in Vue 3 too but the team is moving onto a new hook-like API after cancelling the class based components.

Re: Why I'm still using jQuery

#223

Post by jrandm »

52-6F-62 wrote: post #214
jrandm wrote: post #204

Earlier quoted context omitted.

That's a significantly newer syntax, so I wouldn't say it's "more idiomatic" than explicitly referencing the original function on the prototype (which is idiomatic to JS) and was the way to do it until the spread proposal, Array.from, and similar additions, what, ~5 years ago? If anything isn't that code _less_ idiomatic in that it's less specific to JS and more of a generic operation?

In this instance I understood it to be idiomatic as it calls a JS Array constructor and iterates on the passed parameter to create it. It's been more common than the call/apply methods for years—at least as far as I've seen. The use of the array literal is always preferred, AFAIU.

I agree it'll probably become the new idiom in JS, but it probably needs another few years to begin taking over from the idiom that existed for decades before (and still works).

If you've seen that more common than call/apply for years then you probably work almost exclusively on new projects, with people that convert things to bleeding-edge, or with heavy transpilation: The spread operator as used there has only existed in regular released browsers/node for 3-4 years. I don't think it's a stretch to say the vast majority of code out there at this time won't be doing it that way.

Re: Why I'm still using jQuery

#224

Post by noir_lord »

pier25 wrote: post #222
noir_lord wrote: post #216

Earlier quoted context omitted.

Vue gets that part pretty right at least, they work hard not to break things unnecessarily across versions and never in version (in my experience). Nothing like jQuery's track record but they don't have the history yet to call on.

Yeah, you can still use the component object notation in Vue 2. AFAIK they will keep that in Vue 3 too but the team is moving onto a new hook-like API after cancelling the class based components.

I was bummed they cancelled the class based approach as it’s one I use and like but they did it before 3 was released so not the end of the world.

Re: Why I'm still using jQuery

#225

Post by 52-6F-62 »

jrandm wrote: post #223
52-6F-62 wrote: post #214

Earlier quoted context omitted.

In this instance I understood it to be idiomatic as it calls a JS Array constructor and iterates on the passed parameter to create it. It's been more common than the call/apply methods for years—at least as far as I've seen. The use of the array literal is always preferred, AFAIU.

I agree it'll probably become the new idiom in JS, but it probably needs another few years to begin taking over from the idiom that existed for decades before (and still works). If you've seen that more common than call/apply for years then you probably work almost exclusively on new projects, with people that convert things to bleeding-edge, or with heavy transpilation: The spread operator as used there has only exi…

Yeah could be. And my client base, as it were, are solely internal to the company I work for at this time and we have some knowledge and some cooperation over what versions of browsers people are using when it comes to web-based software. So support for older systems is largely unnecessary. That and building node backends the ES version doesn’t affect them anyway.

Definitely colours my work, and knowledge base.

Re: Why I'm still using jQuery

#226

Post by flukus »

baddox wrote: post #184
Carpetsmoker wrote: post #76

Earlier quoted context omitted.

> 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 towards SPAs and the like. Those are gaining traction because they are easier to develop and easier to maintain. Monumentally so. Let me put it this way, both as a developer and user of SPAs, I have long since observed that SPAs, on average, tend to be much more r…

Do you have an example of a “template app” that has anything even close to the actual feature complexity of an average SPA? Unless you control for that, I’d be willing to guess that the difference in bugginess is simply due to SPAs having a more complex set of features.

> Do you have an example of a “template app” that has anything even close to the actual feature complexity of an average SPA?

How about rewritten apps like reddit, that's as like for like as you can get? There are a bunch of apps/categories (things like JIRA) that were once template style and are now SPA style, the SPA version are nearly always worse.

Re: Why I'm still using jQuery

#227

Post by flukus »

scrollaway wrote: post #161
jlg23 wrote: post #139

Earlier quoted context omitted.

> Has it occured to you you might simply not understand the advantages of this approach? > Putting aside how useful it is to only have one language to learn in a stack... Glad we are not talking about this - I'd have to point out that "I do not have to learn/understand" is a bad continuation when one starts with the claim the other was ignorant.

Why? Decreasing stack complexity is a noble goal, regardless of how familiar you are with the stack as a whole. If a project used both cmake and autoreconf, you'd probably be the first one to call for a rewrite of one to the other (or both to your favourite third). It decreases onboarding time, simplifies hiring, and reduces cognitive load when you yourself have to work with it.

If you want to decrease complexity the first thing to go would be the modern front end stack with it's own build tools, package managers, run times, servers and languages.

Re: Why I'm still using jQuery

#228

Post by jammygit »

candu wrote: post #125
sgift wrote: 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 the part that often gets forgotten in these discussions: it shouldn't be "SPA for everything" vs. "vanilla HTML / CSS / JS for everything"; rather, we should be using the most appropriate set of tools for the job. I've worked on simple static sites, for which I typically lean more on vanilla HTML / CSS with a sprinkling of JS as recommended here. I've also worked on heavy-lifting applications, for which the l…

What are the “indications for use” for a SPA?

Re: Why I'm still using jQuery

#229

Post by andrewf »

Bahamut wrote: post #148
sgift wrote: 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…

I've seen the flip side of the coin in an app I inherited at work - it turns out server-side rendering can be significantly slower than client side rendering if you're rendering a lot of content, to the point where we hit an automatic timeout. If this app was a fat JS app, we probably wouldn't be trying to decommission it & it probably would load in seconds at worst, but the investment to modernize it/improve perform…

Your older app may be serializing a lot of work. For instance, it could be issuing 10 SQL queries, one after another, which take 200ms each to answer - that's 2s total just waiting for the database. Compare to a JS client which issues 10 backend API calls, each being a 200ms request from the server's perspective (and the JS may parallelize many of those requests)

If this is a factor, rearchitecting the backend wouldn't necessarily be easier than an SPA rewrite. But it's not a fundamental limitation of server-side rendering.

Re: Why I'm still using jQuery

#230

Post by maple3142 »

ehnto wrote: post #190
mythrwy wrote: post #171

Earlier quoted context omitted.

element.querySelector('span') would work from parent but not sibling as $(element).next('span') does. You could certainly use that if you selected the parent, then did querySelector from parent (which for all I know is how $(el).next('span') works). So not equivalent, it's an extra step. And that's kind of the point I think. Instead of writing this stuff (with much longer syntax) over and over again, jQuery might be…

Yeah in JS that would be element.parentNode.querySelector('span'). I guess to me, that's not a bad thing. Verbosity is good, it's clear what's happening which leads to fewer unexpected outcomes. What I have learned from this thread is that people don't really like the native versions of these kinds of things, whereas I think the above is much cleaner. It's not my place to say one is correct and one is false, and the…

It is not a equivalent to $(el).next('span') . Your code means selecting the first span in the parent of current element, while the jQuery one means the first span after current element. It will produce different result when there are a span before current element.
Post reply on HN