[SEJeff]

Amusingly, I always joke that I'm fluent in jQuery, but no absolutely no javascript. As a mostly backend go/python/non-javascript developer that has always held true.

It is just a tool in the belt for an engineer. Can you use jQuery in 2022 or later to solve really amazing problems that impact user experience? You sure can! Would you be better off to use a modern javascript variant and stuff like react instead? You also absolutely would.

So just because a tool is old doesn't mean it can't be used to solve real user problems. There are still banks and airlines that run COBOL, and as a user, do you really care that much? I'd take "knows $insert_older_less_hip_tech_here" as experience of having done something for awhile.

Now if I was asked to write a front end today, I'd have to sit down and properly learn react + typescript (because javascript is awful without sensible type checking), and that would add to the time to ship, but is the correct thing to do.

[cogman10]

While I think that’s the right choice, I’d just like to point out that the problem with jQuery today is it was a library built to smooth over and fix differences between browser JavaScript engines (IE, well, IE).

Over the past 15 years or so browser JavaScript engines, except at the extreme edges, are roughly comparable. Further, a lot of the features of jQuery have been adopted into standard JavaScript.

So, the reason of eschewing jQuery, even for small pages, is simply that you don’t need it. Vanilla JS (or typescript) + modern CSS have pretty much all the same capabilities without any of the bloat. Using it today would be a little like using a library made to back port java 8 features onto a java 5 JVM.

[strbean]

> smooth over and fix differences between browser JavaScript engines

And let us avoid some of the extremely verbose and un-ergonomic standard APIs.

[tambourine_man]

Mootools, Prototype, all offered cross browser compatibility.

The reason we're not discussing them today is that jQuery has a stupendous API that simply hasn't been matched yet.

[justbaker]

> Now if I was asked to write a front end today, I'd have to sit down and properly learn react + typescript (because javascript is awful without sensible type checking), and that would add to the time to ship, but is the correct thing to do.

It really is enjoyable working w/ react+typescript. :)

[tinco]

Why react though? Just modern JavaScript (and typescript) is a great replacement for jQuery.

The react part is just for when you need to build something that needs architecture.

[SEJeff]

I primarily did this out of anger and used https://datatables.net to build web based data apps. That’s a really mature and extensible table widget and it would be a shame to not use it as it’s been out years, but in general I know react is how many good modern web apps are written so I’d start there.

[tambourine_man]

>Would you be better off to use a modern javascript variant and stuff like react instead? You also absolutely would.

Why?

[SEJeff]

Because jQuery was written to paper over limitations in ancient browsers that no longer exist, and modern (es6+) vanilla js is actually quite good. One of the primary reasons jQuery was invented is not relevant today. It’s still good software, but I’d say the same about the Perl lwp library yet you don’t see people using it.

[tambourine_man]

Cross browser compatibility was just one of the reasons for jQuery's success. But lots of other competing libraries offered it too at the time. That was the bare minimum a library had to do.

The reason jQuery was so successful, is still so widely used and was instrumental in fomenting HTML5 and killing Flash was its API. Nothing has come close to it in terseness, elegance and power.

Just skim this thread for examples.