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 v4.0 Beta
171–180 of 404 posts
Re: jQuery v4.0 Beta
#172Earlier 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…
Re: jQuery v4.0 Beta
#173Earlier 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.
Re: jQuery v4.0 Beta
#174In 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.
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
#175I'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…
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
#176Earlier 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.…
Re: jQuery v4.0 Beta
#177Earlier 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?
Re: jQuery v4.0 Beta
#178Earlier 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.
Re: jQuery v4.0 Beta
#179I 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...
Re: jQuery v4.0 Beta
#180Earlier 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…