Live data from Hacker News

Why I'm still using jQuery

arp242.net

161–170 of 246 posts

Re: Why I'm still using jQuery

#161
post #139

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

Re: Why I'm still using jQuery

#162
It's a mature library that takes the pain out of cross browser compatibility (yes... you read that right, cross browser compatibility is still a thing in 2019) and the verboseness of using native JS (yes... you read THAT right, using native JS is verbose), so why wouldn't you want to use it?

Oh and on more thing... If you're not using jQuery but instead using native JS with polyfills... YOU ARE A MORON AND DOING IT WRONG and should just you jQuery.

Re: Why I'm still using jQuery

#163

It's a mature library that takes the pain out of cross browser compatibility (yes... you read that right, cross browser compatibility is still a thing in 2019) and the verboseness of using native JS (yes... you read THAT right, using native JS is verbose), so why wouldn't you want to use it? Oh and on more thing... If you're not using jQuery but instead using native JS with polyfills... YOU ARE A MORON AND DOING IT W…

>yes... you read that right, cross browser compatibility is still a thing in 2019

When it comes to manipulating the DOM, I'm not sure it actually is anymore - especially if you can cut out IE11 (and IE11 isn't too bad).

What would be an example of cross-browser compatibility that JQuery takes care of that would be a pain to do with DOM apis.

Re: Why I'm still using jQuery

#164

When you are done designing your Webpage, disable JavaScript, disable CSS (if your browser supports that) and check that you are still able to grasp what you want to present your visitors. If you then don't find the relevant information in the first second, congratulations, you just made a page which is useless to people with old Screen-readers. I may be old fashioned in this regard, but i only see JS as a Add-on to…

>When you are done designing your Webpage

What do you mean by 'webpage'? Because SPAs are really applications that are served over http(s) and executed by the browser.

>I may be old fashioned in this regard, but i only see JS as a Add-on

You are. People want to build applications served over the web instead of installed locally. In those cases JS is not an add-on. In fact, the DOM is an add-on as it is nothing more than a layout manager and UI component set.

Sounds like you just want webpages to be nothing more than a medium for publishing text content in which case CSS and HTML is all you need ... but that ship has sailed in early 2000s.

Re: Why I'm still using jQuery

#165

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?

https://snyk.io/vuln/npm:jquery

Re: Why I'm still using jQuery

#166

Earlier quoted context omitted.

Well, literally not anyone can "throw" such argument, only those who actually has an experience :) How many years of these 15 you are building SPApps? It's ok to disagree. I'm in a camp "API + SPA" after my experience. I know as fact that you can greatly increase UI performance this way and build multiple apps (desktop, mobile, web) using single API. So argument "I just think so" is totally not an argument for me.

I guess the other thing that you’re leaving out is the number of users your site will receive. For smaller numbers in a simpler market you can get away with more technically complex solutions. My last four years have been spent working on data driven platforms with a minimum of a billion individual visits a year, and for those typically prerendering the common parts and pushing them to a caching layer is much more co…

As with many things, the answer is it depends on what you do. I inherited an app that serves about 1m requests a day, and server-side rendering of the HTML is one of the reasons why we're going to decommission this app, as the performance of the server-side rendering here is atrociously bad/unacceptable. We reimplemented many of the same features in a SPA that does a lot more overall and the performance difference is night and day between the two.

Re: Why I'm still using jQuery

#167

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…

There's a mixed-content warning because the original site doesn't have a valid HTTPS cert but yours forces HTTPS, you might want to fix that.

Fixed that and edited it up a bit.

Re: Why I'm still using jQuery

#169
el.insertAdjacentElement('afterend', other) seems a way more intuitive than $(el).after(other). I don't code JavaScript yet the meaning of the first is intuitively obvious to me while I can only know what the second form does because you've told me.

Re: Why I'm still using jQuery

#170
post #138

Earlier quoted context omitted.

element.querySelector('span') is the equivalent. Just as elegant, one fewer function call. 1) People like me care obviously. It's all bike-shedding anyway, so it's just a point of discussion. 2) nextSibling and nextElementSibling are two different properties, and you can't do the former in jQuery at all. In a typical usage you would need to do $('.my-class')[0].nextSibling, or in other words, dig down to the native D…

1. Significantly more functionality than a few edge cases you can no doubt come up with 2. Significantly improved developer experience. 10x reduction in boilerplate === less bugs. 3. Why not improve DX in the platform APIs?

Perhaps that's where the impasse is, because I see the platform APIs to have a reasonable experience now. I much prefer the browser implementations most of the time. Except drag and drop and Ajax. Those are terrible.

I also preferred PrototypeJS over jQuery, it's approach of extending objects made way more sense than a god object that wrapped itself around my existing objects. I have simply never liked jQuery's approach or API.

Post reply on HN