Live data from Hacker News

jQuery 3.6.0

blog.jquery.com

101–110 of 292 posts

Re: jQuery 3.6.0

#101

I'm a happy jQuery/Bootstrap user @ https://forwardemail.net . The site scores ~100% on Lighthouse and PageSpeed Insights and is ranked #1. Open-startup @ https://forwardemail.net/open-startup ! Completely open-source too @ https://github.com/forwardemail

Offtopic but thanks for launching this.

A happy customer.

Re: jQuery 3.6.0

#102
post #6

Do people still use jQuery? I thought the biggest advantage of this library back in the day was css selector access of DOM nodes (back when we only had getElementById, getElementsByClassName, and getElementsByTagName). This has been rolled into the Javascript document api via document.querySelector, and document.querySelectorAll. Also there are browser compatibility issues that jQuery solved but a lot of these are so…

>Do people still use jQuery? Oh yes. Everyday. Still love it. >…Javascript document api via document.querySelector, and document.querySelectorAll The jQuery API is still (and probably aways will be) far superior to the native DOM (terser, composable, more expressive, etc). >…smaller footprint libraries like lodash jQuery is ≈30k gziped and most likely already cached from CDN. >…has fallen out of favor of more compreh…

> IMO, React doesn't bring much to the table in this regard while adding a lot of complexity and heft.

Strongly disagree with this. In any complex web application with a lot of components, specially ones where a lot of fixed components can live for a while, React is definitely a massive improvement over vanilla JS or something like Backbone which allows wild west.

Imagine state coming from sockets, rest APIs etc with updates being either pull or push. A user might do an action which changes the state in some other component, keeping track of the components gets hard if the state is distributed. Also, centrally managed state with things like Redux allows for good caching of API data which can make a SPA considerably fast.

While I love plain HTML pages which need little or no JS, a lot of applications are better as SPAs.

Re: jQuery 3.6.0

#103
post #53
post #22

Earlier quoted context omitted.

I think a lot! For example, the new https://www.whitehouse.gov uses jQuery. When you just want to add a small bit of interaction to a mostly-static site, jQuery can help. There's a current trend to complicate things with a JAM stack that really don't need to be complicated. I've seen people propose something like [NodeJS/Ruby/PHP backend] -> GraphQL API -> React Frontend -> static html Where really they could have ju…

I do think in some cases SPA make sense, but in many other cases just using a bit of jQuery/vanilla js to add a bit of interaction is enough. Server side rendering is way easier to do and is often faster to load for the client.

SPA make sense whenever you want to write a proper application running in the browser. When you just want a website, stop the SPA madness.

Re: jQuery 3.6.0

#104
post #57
post #14

Earlier quoted context omitted.

Please elaborate about toString() ?

The toString() method returns a string representing the source code of the function. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

That's pretty neat. Thanks for the link.

Re: jQuery 3.6.0

#105
post #6

Do people still use jQuery? I thought the biggest advantage of this library back in the day was css selector access of DOM nodes (back when we only had getElementById, getElementsByClassName, and getElementsByTagName). This has been rolled into the Javascript document api via document.querySelector, and document.querySelectorAll. Also there are browser compatibility issues that jQuery solved but a lot of these are so…

>Do people still use jQuery? Oh yes. Everyday. Still love it. >…Javascript document api via document.querySelector, and document.querySelectorAll The jQuery API is still (and probably aways will be) far superior to the native DOM (terser, composable, more expressive, etc). >…smaller footprint libraries like lodash jQuery is ≈30k gziped and most likely already cached from CDN. >…has fallen out of favor of more compreh…

> jQuery is ≈30k gziped and most likely already cached from CDN.

This part isn't so true in reality anymore, due to revised browser caching systems[1]. Doesn't mean you shouldn't use jQuery, just that part of the benefits of a centralized CDN are no longer a factor and it's a lot more sensible to self-host.

1: https://www.stefanjudis.com/notes/say-goodbye-to-resource-ca...

Re: jQuery 3.6.0

#106

Earlier quoted context omitted.

> When you just want to add a small bit of interaction to a mostly-static site Then I'd reach for Alpine. Very lightweight, and I can use the fetch API instead of $.ajax.

Jquery has been around for 14 years. That framework..16 months. You want to be as confident as possible you can bump to a new version on your old site in 4 years if you have to? Use Jquery.

Plus it's easier to hire for. Chances are more developers have experience with JQuery than .

Re: jQuery 3.6.0

#107
post #6

Do people still use jQuery? I thought the biggest advantage of this library back in the day was css selector access of DOM nodes (back when we only had getElementById, getElementsByClassName, and getElementsByTagName). This has been rolled into the Javascript document api via document.querySelector, and document.querySelectorAll. Also there are browser compatibility issues that jQuery solved but a lot of these are so…

>Do people still use jQuery? Oh yes. Everyday. Still love it. >…Javascript document api via document.querySelector, and document.querySelectorAll The jQuery API is still (and probably aways will be) far superior to the native DOM (terser, composable, more expressive, etc). >…smaller footprint libraries like lodash jQuery is ≈30k gziped and most likely already cached from CDN. >…has fallen out of favor of more compreh…

[deleted]

Re: jQuery 3.6.0

#108
post #22

Earlier quoted context omitted.

I think a lot! For example, the new https://www.whitehouse.gov uses jQuery. When you just want to add a small bit of interaction to a mostly-static site, jQuery can help. There's a current trend to complicate things with a JAM stack that really don't need to be complicated. I've seen people propose something like [NodeJS/Ruby/PHP backend] -> GraphQL API -> React Frontend -> static html Where really they could have ju…

There's no need to complicate static sites with jQuery. All it does can be achieved with vanilla.

As a competitive code golfer, I can confidently say that vanilla JS has never offered the raw performance of jQuery.

Re: jQuery 3.6.0

#109
post #6

Do people still use jQuery? I thought the biggest advantage of this library back in the day was css selector access of DOM nodes (back when we only had getElementById, getElementsByClassName, and getElementsByTagName). This has been rolled into the Javascript document api via document.querySelector, and document.querySelectorAll. Also there are browser compatibility issues that jQuery solved but a lot of these are so…

Still use it. Still love it.

Just last month I decided to toss a quite arbitrary `=>` in my javascript (I still write `function (args) { code }`), and shipped it. Immediately got a _TON_ of user complaints.

Turns out, we sent a link in a newsletter, and most folks were reading those in Outlook, and that evidently just opens links internally, and that is still IE11. We don't ordinarily support IE11, but given that this is a specific info page shown there, for this we make an exception, and... => doesn't even work there.

Thus, another year goes by, and another year where I am 100% convinced it is totally not worth my time or effort to investigate newer options.

I'm honestly confused about why jQuery is considered 'bad'.

It's a dependency - yeah, 30k or so. This complaint (that it adds load time) boggles my mind; in this day and age of 10MB+ load pages, and the choice is to complain about a 30k library? Some javascript-library variant of the Total Perspective Vortex may be warranted to try to make sense of this.

A more interactive (as in, between server and browser), more stateful integrated model? Oh, yeah, totally, I can see that, but that 'formula' surely isn't the go-to strategy for every web page out there, right? Most of the pages I write work perfectly well via a 'server generates data, server throws it through a template and sends it to browser, client downloads jquery and some javascript for that page which adds interactive elements', and wouldn't be any 'nicer' if it was a much more javascript-native fully state-shared amalgamation. When I do need that live-updating stateful interaction model, sure, don't need jQuery. But that 30k is the least of my worries if that happens.

Re: jQuery 3.6.0

#110

Earlier quoted context omitted.

>Do people still use jQuery? Oh yes. Everyday. Still love it. >…Javascript document api via document.querySelector, and document.querySelectorAll The jQuery API is still (and probably aways will be) far superior to the native DOM (terser, composable, more expressive, etc). >…smaller footprint libraries like lodash jQuery is ≈30k gziped and most likely already cached from CDN. >…has fallen out of favor of more compreh…

> IMO, React doesn't bring much to the table in this regard while adding a lot of complexity and heft. Strongly disagree with this. In any complex web application with a lot of components, specially ones where a lot of fixed components can live for a while, React is definitely a massive improvement over vanilla JS or something like Backbone which allows wild west. Imagine state coming from sockets, rest APIs etc wit…

That's more like redux and company...
Post reply on HN