Live data from Hacker News

jQuery v4.0 Beta

blog.jquery.com

171–180 of 404 posts

Re: jQuery v4.0 Beta

#171

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…

jQuery is amazing, still remember the joy of using it 20 years ago. That being said, React, Vue and similar are just better IMO to build and maintain complex apps. Don't get me wrong, jQuery was the best thing at its time and I will always be grateful to its contributors, but today there are better alternatives. I think htmx is nice but not seeing it taking over other frameworks.

Re: jQuery v4.0 Beta

#172
post #150

Earlier quoted context omitted.

Yup, hard truths: vanilla JS is far less readable and clunkier than just using jQuery to do the same thing. Also, not everyone needs or wants to move to a shadow DOM framework with a zillion components and high complexity. If you're building a SPA or PWA, yes, absolutely, but for the vast majority of us who use a traditional backend/CMS-driven site with server-side rendering where client-side interactivity is needed,…

Now I might not know what I'm missing out on since I haven't worked in any projects w/ jQuery as I haven't been developing websites for a long time (and the type of sites I make probably also influences the stack), but there's probably something that does what you want as elegantly without jQuery. We have stuff like querySelector and toggle in vanilla JS that makes it possible to change state simply, async stuff is m…

If you're creating a fully interactive webapp (google maps, docs, or apple music), go with one of the frontend frameworks because they will give you a much simpler way of managing states and binding it to the view layer. But the majority of websites are not apps or shouldn't be. You'd only have a couple of interactive elements if you strip the UX to its core. And that can be done easily with server rendered templates and a bit of jquery/vanilla js.

Re: jQuery v4.0 Beta

#173

Earlier quoted context omitted.

You sure can, but it then comes to the separation of concerns. CSS-in-JS (coupling of concerns) is the preferred option.

Having CSS in a separate file feels like defining the predicates for your if statements in a separate file. With tailwind we're getting pretty close to a great solution here.

[dead]

Re: jQuery v4.0 Beta

#174
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.

Solo or small team devs who hate modern tooling. Good example is levelsio guy: https://twitter.com/levelsio/status/1750175827197567165

I'm also in that camp and still use jQuery.

My current SaaS is an extension that doesn't have much UI code https://www.snipcss.com, and my next SaaS will be a chatgpt powered web automation extension that has a good amount of UI. Both use jQuery.

Edit: I didn't say why I don't just use vanilla with querySelectorAll - majn reasons are I like how I can attach events (attaching to parent while targeting dynamically added subelements), chaining functions, and it's just less code than vanilla

Re: jQuery v4.0 Beta

#175
post #41

I'm consistently surprised by the commenters on HN who seem to think jQuery is just a DOM selection library, when in fact it is a widely supported, incredibly stable tool set for (yes) DOM selection, but also attribute manipulation, Ajax requests, event handling, animation, and general utility functions. What's more, where there _is_ native functionality that replaces jQuery, the API is never as fluent. For work that…

A few years ago I dropped jQuery for plain vanilla js and I've never looked back. Native js has everything jQuery has, except for the pile of often poorly maintained half baked "plugins", that usually only do what they want to do and not much else. Yes, the vanilla selectors are more verbose, but any half decent code editor will make them just as fast to type. I don't mean to be penantic, but I don't really understan…

> Native js has everything jQuery has, except for the pile of often poorly maintained half baked "plugins"

The great things about these plugins is that you can strip them down to what you need and patch them yourself (remember lib or vendor directory). NPM and build tools make this a chore.

Re: jQuery v4.0 Beta

#176
post #154
post #92

Earlier quoted context omitted.

You would just do: const response = await fetch(...) Bam, now you have the response without needing callbacks.

The async/await design is absolute garbage and no one will ever convince me otherwise. `fetch` is a particularly egregious example: it has all kinds of insane random quirks that you need to memorize. For example, how do I handle an error there? What's the obvious way to handle it? Is response null or something? Well, not exactly, you need to check for: response.ok; // false response.status; // 404 Um, okay, I get it.…

There are many popular wrappers like axios that fix some of these things.

Re: jQuery v4.0 Beta

#177
post #81

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…

>But jQuery doing dynamic binding to dynamically generated forms Do you have an example of that?

Hold my beer!

https://alive22-dev.turnaroundhealth.com/static/javascript/q...

Re: jQuery v4.0 Beta

#178

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 remains the best JSONP library. It can get data even when other libraries are blocked.

If I understand this announcement correctly, they removed support for JSONP

Re: jQuery v4.0 Beta

#179
post #45
post #33

I like Vue's reactive nature the best (specifically `v-if`, `v-for`), but jQuery was the one that got me over the hump before I actually knew Javascript. And I encourage most projects that use a lot of jQuery to consider using jQuery's CDN version as there is like a 50%+ chance the person already has it cached on their system.

This hasn't been the case for about four years. Since you can use cache status to track people, resources are now cached per hostname requesting as well. https://www.stefanjudis.com/notes/say-goodbye-to-resource-ca...

This feels like it is still pretty good when you are on a common host like github pages.

Re: jQuery v4.0 Beta

#180
post #47

Earlier quoted context omitted.

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

I started with Jquery, I learned React. I prefer React. React complexity is often conflated with things like Next JS or other SPA solutions. React was originally meant to be a library for building small components that you drop into an otherwise static websites. But people usually don't talk about React unless they're talking about whole sites being in React. For that reason, I think its complexity is exaggerated. Mo…

React was developed by Facebook. I don't think they did it for small components on otherwise static sites.
Post reply on HN