Live data from Hacker News

jQuery v4.0 Beta

blog.jquery.com

51–60 of 404 posts

Re: jQuery v4.0 Beta

#51

For those of you who are curious what drives jQuery in 2024 and beyond, you need to remember that WordPress is still more than 1/3 of the web, and the majority of installations and so many plugins critically rely on jQuery. Yes, seriously. Any advances to removing deprecated APIs or functions are great. jQuery will probably be around dominantly on the web for years to come.

Also, jQuery is awesome. People have been in love with the overly complex and fancy javascript frameworks for the last 15 years or so. But jQuery doing dynamic binding to dynamically generated forms for some error states and maybe an ajax calls is literally all the javascript you need in 99% of web pages and the rest is overkill. The industry is going to move away from the complexities to React and towards more of th…

I'm not a web developer but sometimes I have to make a page with some JS functionality. jQuery saves me a lot of time in such cases

Re: jQuery v4.0 Beta

#52
post #14
post #8

Earlier quoted context omitted.

Because I'm old and new tricks are less interesting, I find $.ajax() much more simple than promise, await, async of native JS. I have used straight native JS on a couple of smaller personal projects just to get some familiarity with it. However, it's just muscle memory type of getting stuff done with $.ajax() for me. Also, maybe 20 people use any of the code I write for manipulating DOM. I'm not a UI person. I'm a ba…

It’s only simpler because you know how to use it. For most use cases fetch and async/await is just easier.

I mean, duh? Of course doing something that I've done for a long time is going to be more simple to me than me fumbling/stumbling through something I haven't done much. What new insight are you providing me here?

Re: jQuery v4.0 Beta

#53

Earlier quoted context omitted.

Also, jQuery is awesome. People have been in love with the overly complex and fancy javascript frameworks for the last 15 years or so. But jQuery doing dynamic binding to dynamically generated forms for some error states and maybe an ajax calls is literally all the javascript you need in 99% of web pages and the rest is overkill. The industry is going to move away from the complexities to React and towards more of th…

jQuery is not awesome. It was awesome 15 years ago. Now it's completely outdated. It's very hard to reason about DOM that can be manually changed by any random piece of code. That's why declarative solutions like React/Vue/Svelte are so much better.

It's good for quick things and prototyping cause you can always swap out those calls with native later. It's API is generally easier to remember/less typing that most native equivalents. You can also use its API serverside via Cheerio to do parsing & manipulation of html without a dom.

edit: also its way more lightweight than React/Vue/Svelte i don't necessarily disagree you shouldn't reach for jQuery if you have a dynamic page (something like uhtml+preact signals would be good if you have fair bit of rendering logic going on) but I would say you should totally try seeing how far you can get with jQuery instead of Svelte/React/Vue on simple pages.

Re: jQuery v4.0 Beta

#55

Earlier quoted context omitted.

Also, jQuery is awesome. People have been in love with the overly complex and fancy javascript frameworks for the last 15 years or so. But jQuery doing dynamic binding to dynamically generated forms for some error states and maybe an ajax calls is literally all the javascript you need in 99% of web pages and the rest is overkill. The industry is going to move away from the complexities to React and towards more of th…

jQuery is not awesome. It was awesome 15 years ago. Now it's completely outdated. It's very hard to reason about DOM that can be manually changed by any random piece of code. That's why declarative solutions like React/Vue/Svelte are so much better.

Different use cases. A lot of the web only has only one or two interactive elements in a scope. The DOM being changed by any random piece of code is not a problem when all of the JavaScript fits on two screens. In fact, it’s a benefit here.

Re: jQuery v4.0 Beta

#56
post #43

Earlier quoted context omitted.

I remember switching from mootools to jQuery back in 2006ish. Thought it was fantastic. Awesome it’s still around. We still use it from Time to time.

Don't forget Prototype ( http://prototypejs.org/ )

and scriptaculous!

http://script.aculo.us/

Re: jQuery v4.0 Beta

#57
post #39
post #9

Earlier quoted context omitted.

There's a bunch of pretty convenient selectors that are not supported by document.querySelector(), such as :selected, :checked and a bunch of others (I forgot which exactly, but I've run in to it a few times). In general the DOM API offends pretty much every single of my sensibilities on how to design good APIs. I also have some gripes with the jQuery API, but it's a lot better. jQuery just reads and writes so much m…

:checked is standard CSS, and old.

Eh, do'h, of course. There's a few selectors anyway, but I'd have to check which ones exactly. :eq(n) and :visible from a quick check (:nth-child(n) can replace :eq(n) in some cases, but not all).

Re: jQuery v4.0 Beta

#58
post #47

Earlier quoted context omitted.

jQuery is not awesome. It was awesome 15 years ago. Now it's completely outdated. It's very hard to reason about DOM that can be manually changed by any random piece of code. That's why declarative solutions like React/Vue/Svelte are so much better.

>It's very hard to reason about DOM I don't mean to be overly snarky here, but as someone who's just totally out of their depth in modern web UI - is that why people like these frameworks? Because they're very easy to reason about? I've generally found them to be mountains and mountains of boilerplate and spaghetti, but I really do not have a wide base of experience to pull from on this topic.

[dead]

Re: jQuery v4.0 Beta

#59
post #8
post #2

In a world where many of us are actively trying to remove the last vestiges of jQuery, who is actively developing using jQuery? Genuinely curious. I’ve found that most of what I went to jQuery before is baked in now. querySelectorAll being the most powerful.

Because I'm old and new tricks are less interesting, I find $.ajax() much more simple than promise, await, async of native JS. I have used straight native JS on a couple of smaller personal projects just to get some familiarity with it. However, it's just muscle memory type of getting stuff done with $.ajax() for me. Also, maybe 20 people use any of the code I write for manipulating DOM. I'm not a UI person. I'm a ba…

> I find $.ajax() much more simple than promise, await, async of native JS.

$.ajax() returns a promise. If you're calling .done() / .error() on it to handle the results -- well, that's exactly how you work with promises.

Re: jQuery v4.0 Beta

#60
post #47

Earlier quoted context omitted.

jQuery is not awesome. It was awesome 15 years ago. Now it's completely outdated. It's very hard to reason about DOM that can be manually changed by any random piece of code. That's why declarative solutions like React/Vue/Svelte are so much better.

>It's very hard to reason about DOM I don't mean to be overly snarky here, but as someone who's just totally out of their depth in modern web UI - is that why people like these frameworks? Because they're very easy to reason about? I've generally found them to be mountains and mountains of boilerplate and spaghetti, but I really do not have a wide base of experience to pull from on this topic.

That's one of the reasons I like them, yes. I've done a lot of manual DOM manipulation, and a lot of jQuery. When you're building anything complex, it starts to become quite difficult to figure out why a particular piece of the DOM is behaving the way it is. It could be an overly aggressive selector that accidentally targeted it, or any number of things.

Prior to React (and similar libraries), DOM manipulation was generally done in a mutating, effectful way. With React (and similar), if a thing is behaving strangely, I just need to go to the component that rendered said thing, and I can almost always find the problem.

Post reply on HN