Live data from Hacker News

jQuery 4

blog.jquery.com

91–100 of 313 posts

Re: jQuery 4

#91
post #51

Whenever HTMX comes up here, I always think "isn't that just some gobbledy-gook which replaces about 3 lines of imperative jquery?" Anyway, jQuery always did the job, use it forever if it solves your problems.

These days I’ve moved to native JS, but hot damn the $() selector interface was elegant and minimal vs document.getElement[s]by[attribute)]. While presumably jquery is slower than native selectors, maybe that could be pre-computed away.

jQuery but gets compiled out like svelte... Not a bad idea at all.

Re: jQuery 4

#92
post #23

Earlier quoted context omitted.

I used this approach before and it indeed works better than the 2010-style jQuery mess. A good fit for userscripts too, where the problem you attempt to solve is fairly limited and having dependencies, especially with a build steps, is a pain. Note that you don't need jQuery for this at all, unless you are somehow stuck with ancient browser support as a requirement - querySelector, addEventListener, innerHtml - the b…

Unfortunately, nowadays writing userscripts is much harder than it used to be. Most websites are using some sort of reactive FE framework so you need to make extensive use of mutationObservers (or whatever the equivalent is in jQuery I guess).

I often go for `setInterval` over `MutationObserver` because it works and I don't need instant reactivity and I don't have to think too much about it.

Re: jQuery 4

#93
post #51

Whenever HTMX comes up here, I always think "isn't that just some gobbledy-gook which replaces about 3 lines of imperative jquery?" Anyway, jQuery always did the job, use it forever if it solves your problems.

These days I’ve moved to native JS, but hot damn the $() selector interface was elegant and minimal vs document.getElement[s]by[attribute)]. While presumably jquery is slower than native selectors, maybe that could be pre-computed away.

In case you missed them: check out querySelector and querySelectorAll. They are closer to what the jQuery selector system does, and I think they were inspired by it.

If the verbosity bothers you, you can always define an utility function with a short name (although I'm not personally a fan of this kind of things).

https://developer.mozilla.org/docs/Web/API/Document/querySel...

https://developer.mozilla.org/docs/Web/API/Document/querySel...

https://developer.mozilla.org/docs/Web/API/Element/querySele...

https://developer.mozilla.org/docs/Web/API/Element/querySele...

Re: jQuery 4

#94
post #84
post #3

Nice to see it still around and updated. The sad part is I guess this means React will be around in 2060.

What's wrong with React? It made it so much better to build apps vs. spaghetti jQuery. I still have nightmares about jeeping track of jQuery callbacks

The problem with React is that it solved frontend.

So the options are to 1. Code React all day and be happy with it. 2. Come up with reasons why it's bad.

There are many talented and intellectually curious people in the field which lean towards 2.

Re: jQuery 4

#95
post #54

Earlier quoted context omitted.

Very true. I guess that depends on what websites you find issues with? I just checked mine and all of those are quality of life improvements for fully server rendered sites like HN or phpBB forums.

Yeah, I mostly use it for QoL improvements but for work related things. So Jira, Bitbucket, GitHub, Linear etc. basically whatever my employer uses. Back in the early 2010s most of that software was fully server rendered. Nowadays it's pretty rare for that to be the case. I just try and get LLMs to do it for me because I'm lazy, and they like to use setInterval instead of mutationObservers and if it works, I just liv…

The Atlassian stack is particularly bad to extend IMHO given that there are sooooo many API endpoints that their UI calls and most of them are dog slow.

Re: jQuery 4

#96
post #39

Earlier quoted context omitted.

Not everybody in the world can use modern hard- and software. There are tons of school computer labs running old software

Yes, run jQuery 3. Crazy to think that software running inside IE11 should use the latest version of a library.

[deleted]

Re: jQuery 4

#97
post #47

Earlier quoted context omitted.

Who is still stuck on IE 11---and why?

There are some really retrograde government and bigcorps, running ten year old infrastructure. And if that is your customer-base? You do it. Plus I worked on a consumer launch site for something you might remember, and we got the late requirement for IE7 support, because that's what the executives in Japan had. No customers cared, but yeah it worked in IE7.

Oh, certainly, corporations run ten-year-old software. But for the record, IE 11 turns 13 this year [1]. Which makes it somewhat more surprising to me.

[1] https://en.wikipedia.org/wiki/Internet_Explorer_11

Re: jQuery 4

#98
post #78

It's amazing how much jQuery is still used today. Even on modern websites you can often find it included (browser devtools -> jQuery in the console, and see). And not just on hobbyist sites, but on serious company websites and their web tools as well.

Curious: Whats the current behemoth instead of JQ? I perceive it as still being the de-facto standard?

Many things JQ introduced are browser native now.

Re: jQuery 4

#100
post #4

Earlier quoted context omitted.

Backwards compatibility. Apparently there are still some people stuck on IE11. It's nice that jQuery still supports those users and the products that they are still running.

This is the part that I find the strangest: > We also dropped support for other very old browsers, including Edge Legacy, iOS versions earlier than the last 3, Firefox versions earlier than the last 2 (aside from Firefox ESR), and Android Browser. Safari from iOS 16, released in 2022, is more modern in every conceivable way than MSIE 11. I'd also bet there are more people stuck with iOS 16- than those who can only us…

It’s rarely a horrid IT department but some special or legacy software without modern replacement
Post reply on HN