22 ms·

jQuery v4.0 Beta

569 points by joshmanders 3y ago

voidwtf 3y ago
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.
- dylan604 3y ago
  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 back end person that has to write front end stuff because nobody else does it.
  - lakpan 3y ago
    It’s only simpler because you know how to use it. For most use cases fetch and async/await is just easier.
    - dylan604 3y ago
      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?
      - umvi 3y ago
        Async await fetch lets you flatten your nested callback functions into simple procedural programming. It makes everything much easier to reason about, no more closures and such.
        dylan604 3y ago
        see, this is where i'm not cool with this newness. i've spent years getting away from procedural, and switching to functions, classes/methods. now, we want to get away from that and go back to procedural? that's all fine and dandy, but you're trying to have a new trick conversation with an old dog that just doesn't care. you're bringing some sort of logic to a conversation where it's not needed. it works for me. i don't get paid to make UI apps or write heavy code nonsense with server side JS. i use a proper back end language. JS can stay in the browser and manipulate the DOM thank you very much. i get paid to make heavy processing code that sometimes is helpful to have UI dashboards. i can whip up a JQuery front end faster for my needs than most can even figure out what NPM librar[y|ies] they need to use
        boredtofears 3y ago
        surely you still use procedural code within your functions and classes. the point of await/async is you break down the callback nesting into a single set of procedural code. it doesn't mean all your code is procedural. just that what used to have to be a series of indented anonymous functions or spread all over the place named functions can now be an easy to read concise few lines of code all at the same indentation in a single spot. its an obvious net-win for readability and code maintainability. you are doing yourself no favors by not understanding/embracing it.
        deleted 3y ago
        [deleted]
        marcosdumay 3y ago
        > now, we want to get away from that and go back to procedural? AFAIK, we are all still programming browser UI with Javascript. It is an imperative language, about as stateful as you can get. Now, if you managed to do your frontends with Haskell or Prolog, I'd be interested on learning how.
        zdkl 3y ago
  - duskwuff 3y ago
    > 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.
    - dylan604 3y ago
      you think it's the same, but it's not even close to me .ajax({ success:function(result), error:function(xhr), } vs fetch().then((e)=>function()) is even close to being the same, then we're just not even talking the same language
      - umvi 3y ago
        You would just do: const response = await fetch(...) Bam, now you have the response without needing callbacks.
        dvt 3y ago
        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. So to get the text content of the response, I just need to do response.text, right? No, you dummy, that's a function! You need to call response.text(), duh. It's so funny how an entire generation of front-end engineers just accepted this slop as acceptable API design. You can't fix the past, but thank God for (oh the irony) Microsoft and TypeScript.
        n_plus_1_acc 3y ago
        There are many popular wrappers like axios that fix some of these things.
        3y ago
  - austin-cheney 3y ago
    WebSockets are easier and faster.
- kxrm 3y ago
  > who is actively developing using jQuery? Yea same, I am actively trying to get rid of jQuery, but my guess would be people get used to working with a tool and there just isn't enough desire or a business case to get rid of it as it would require a rewrite. I would say that I doubt new projects are starting with jQuery but I know there are devs out there that know the jQuery way better than the vanilla javascript way to get things done.
  - MBCook 3y ago
    But if you don’t want to get rid of it for business reasons, which I get, a major upgrade that changes a bunch of APIs and drops features would still require a lot of work. And if you’re forced to leave 3.x over security or something (may happen in the future) then why not just move off then?
    - dylan604 3y ago
      I'd imagine upgrading from JQuery 3.x to 4.0 will be much less hassle than starting from essentially a blank page even if you were using some of the deprecated methods (even though you've previously been warned).
    - kxrm 3y ago
      Yea, see the last half of my comment. There is a lot of legacy knowledge around how jQuery handles things and there are devs out there who just aren't interested in learning how to do it without jQuery. For their customers and users, it makes no difference.
- lawgimenez 3y ago
  Based on last year’s Stack survey, JQuery is the third popular. https://survey.stackoverflow.co/2023/#section-most-popular-technologies-web-frameworks-and-technologies https://survey.stackoverflow.co/2023/#section-most-popular-t...
  - notso411 3y ago
    [dead]
- sublinear 3y ago
  There are plenty of legacy web projects still using jQuery that nobody has been able to replace. Off the top of my head I'm thinking of complex boring stuff like WCAG-compliant carousels or whatever. The kind of libraries people tend to reach for because marketing wanted them, but are otherwise ignored.
- ahmedfromtunis 3y ago
  Django uses jQuery for its admin interface. (That is, jQuery is used by the Django maintainers to write the built-in admin interface.) But I also know that a lot of the "low-cost" agencies are still using it. Probably because de the devs are used to using and don't want to bother to (re)learn things. At least in my country, a lot of website are still using it (and very old, outdated versions at that).
- arp242 3y ago
  The DOM API now solves a lot of the issues jQuery solved 15 years ago, but often in very different ways. I don't think it's better; a lot of the APIs are awkwardly designed IMO. The big upshot is that it's built-in, but that's it, and with a very small jQuery library you get a nicer API. Sometimes the extra dependency is best avoided, but often it doesn't matter. So, whenever reasonable, I prefer to just add jQuery. Maybe there's something better, but the differences/improvements of what I've seen doesn't seem that great and jQuery works, so that's the point? I guess the younger kids never used it, but it's easy enough to pick up if you know standard JS.
- sam0x17 3y ago
  It's funny, I just spent a bunch of time removing the last vestiges of react for a company, replacing it with HTMX, which imo is the spiritual successor to jQuery in some ways
- mhitza 3y ago
  I wouldn't exclude the possibility of new developers that found some stackoverflow answer, or another, which suggests jQuery as the solution.
- miragecraft 3y ago
  jQuery is still excellent if you are creating websites (not web apps) with minimal JavaScript.
- deleted 3y ago
  [deleted]
- mrieck 3y ago
  Solo or small team devs who hate modern tooling. Good example is levelsio guy: https://twitter.com/levelsio/status/1750175827197567165 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 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
- gexla 3y ago
  I'm guessing most active development which people are actually consuming. Already mentioned is Wordpress, which is most of the web. There's probably tons of front-ends using old Bootstrap which also came with Jquery. Greenfield projects might not be using Jquery, but is anyone actually using those? ;)
- AdrianB1 3y ago
  I am using it when I need AJAX + Datatables for quick, but not dirty pages showing data in different ways that takes minutes to set up. Actually my projects are native JS for most and jQuery for that specific combination above. These are not public or commercial apps, just internal use for my department. I am not even a developer by role, but I build stuff when needed and time allows it.
OccamsMirror 3y ago
With browsers having much better support with DOM selection, why would anyone be using jQuery in 2024? Not trying to throw shade, I actually think it's cool that it's still being worked on. But I'm confused as to what the use case is.
- anamexis 3y ago
  If I had to guess, a convenient API and a massive ecosystem.
- arp242 3y ago
  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 more fluently.
  - evan_ 3y ago
    `:visible` and `:hidden` are really cool
    - senfiaj 3y ago
      In my opinion selecting something based on it's layout is oftentimes a dangerous pattern, you are basically tying the UI layout with the logic. People can overuse these cool selectors. I've personally worked on a website where the frontend part was a spaghetti mess with the half of the source code occupied by selector names. Some files have over 5000 lines of code. It would be far less pain to maintain and implement features if the website used some framework like angular.
  - mkl 3y ago
    :checked is standard CSS, and old.
jszymborski 3y ago
Bring yayQuery back. The people demand it.
technojunkie 3y ago
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.
- ecshafer 3y ago
  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 this simplicity with htmx, phoenix live view, ruby on rails turbo, and yes just jQuery.
  - bufferoverflow 3y ago
    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.
    - rjbwork 3y ago
      >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.
      - auxfil 3y ago
        [dead]
synergy20 3y ago
Most elegant API for Javascript, can it become part of Javascript API directly one day?
didip 3y ago
Great job jQuery folks! I will forever love jQuery. It simply gets the job done.
- 5350-uiop-1130 3y ago
  Bootstrap, PHP, JQuery & WP. The stack for people who get shit done.
ActualHacker 3y ago
I was evaluating a SaaS solution just yesterday, and in one of their examples on Github they used jQuery as the primary frontend for the project, with extensive usage. I passed on the company
- jraph 3y ago
  Why? What's wrong, if it works well?
  - paulddraper 3y ago
    There are things that work better.
    - jraph 3y ago
      Seems a weak reason for rejecting a solution and this is subjective. I prefer native JS but something can be well designed in jQuery.
    - wiseowise 3y ago
      Define “better”.
      - paulddraper 3y ago
        More succinct, fewer bugs.
- kmoser 3y ago
  With SaaS, the front end might be the least important piece of the application.
- cynicalsecurity 3y ago
  Too bad for you. I'm glad for them they don't have to deal with you as a customer.
wkirby 3y ago
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 needs a little enhancement on top of server-side HTML, but not a full-blown JS UI framework, jQuery is a small price to pay for a stable, reliable, and cross-browser compatible dependency.
- genocidicbunny 3y ago
  I don't think it's that surprising given the demographics of HN posters that I've observed. Many will immediately reach for the big JS framework du jour when they need anything more than a little DOM selection stuff, because that's what they've always done.
  - erhaetherth 3y ago
    There's 2 types of web pages. Websites and web apps. If you're building a web app, you're going to want a framework that isn't going to fall apart the second things start getting complicated. If you're making a little marketing website, sure, sprinkle some jQuery on there and call it a day. Probably better for performance and SEO unless you want to spend 10x as long micro-optimizing your SSR. Point is, there's different use-cases.
    - genocidicbunny 3y ago
      Okay, what part of what I said are you trying to refute or educate me on? There's a large proportion of posters on HN who spend their days building web apps. They are very likely to stick to using what they know, even when building web sites. If you spend your days working as a welder, and suddenly need to build a box for some reason, you're probably not going to be breaking out the fine wood joinery tools. You're probably going to take some sheet steel and weld up a box and move on to whatever else you have to do. It's not a problem, it's not a fault, it just how things are.
nfriedly 3y ago
I remember building web apps in the days before jQuery, it was a mess. The DOM APIs were full of quirks, and all the libraries that predated jQuery had their own issues. These days, we have better options for building complex web apps, including much-improved native APIs. I don't think I've started a new project using jQuery in 10 years. But for maintainin a lightweight website that just needs a little bit of interaction or pizzazz, I still think jQuery is perfectly fine.
- yread 3y ago
  Especially the events! Those were browser-specific nightmares
  - senfiaj 3y ago
    Today it's not nearly as bad as it was before. I personally have very few reasons to use jQuery. Maybe it's somewhat shorter code and supports some cool pseudoselectors (IMHO, they are often bad patterns) but for me it's often easier to understand and debug a code using vanilla JS. For example, sometimes I have struggled to find the exact event listener callback by using dev tools because when you use nested click events because the code passes throw a lot of jQuery code before reaching the actual event listener.
andirk 3y ago
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.
- notzane 3y ago
  Doesn’t work anymore :( https://news.ycombinator.com/item?id=24894135 https://news.ycombinator.com/item?id=24894135
  - andirk 3y ago
    Wow! I'm embarrassed I didn't know this since 2020. Too bad we can't allow certain super popular libraries of whose project maintainers we trust to still be cached across domains.
- deleted 3y ago
  [deleted]
- nsp 3y ago
  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-caching-across-sites-and-domains/ https://www.stefanjudis.com/notes/say-goodbye-to-resource-ca...
  - lenkite 3y ago
    This feels like it is still pretty good when you are on a common host like github pages.
mholt 3y ago
I loved jQuery. Still great, but browser APIs have improved. Now I mainly use AJQuery: https://github.com/coolaj86/ajquery.js/blob/main/ajquery.js https://github.com/coolaj86/ajquery.js/blob/main/ajquery.js
DonnyV 3y ago
A lot of what jQuery was created to do is now baked into the browser. CSS selectors, proper ajax, animation, etc. I built a small convenience library around fetch to make it super easy to use ajax like in jQuery. Also built a small utility library around ES6 methods that recreate jQuery methods. It doesn't take much to get back the convenience of jQuery but still use all the new tools. I love jQuery and used it for years. But there are better tools now.
hallman76 3y ago
Just in case folks aren't familiar, this site breaks down jQuery features into web standard code: https://youmightnotneedjquery.com/ https://youmightnotneedjquery.com/
voat 3y ago
Another day another JavaScript framework! I'm so tired of all this churn in frontend. /s
mm007emko 3y ago
I remember jQuery from it's heyday when we used it as a replacement for Mootools. Since many people are going from React to HTMX, maybe we've made a full circle and we'll see web using just plain jQuery as well?
- evilduck 3y ago
  I came up in a similar era, I don’t think back fondly on those messes. Doing a modern app with accessibility, mobile support, real time updates, visualizations, and maybe a few PWA features with just jQuery sounds incredibly unpleasant. I’m waiting for the HTMX hype train to meet reality too. Programming your app in pseudo attributes with a DSL is going to wear thin quickly.
  - mm007emko 3y ago
    I think that many websites even nowadays don't need all that jazz and many would improve if less JavaScript was on them. How many times have you loaded a website only to watch a couple of JavaScript "spinners" for everything to load only to click somewhere and everything started again? MS Azure management is one of such sites. SPA with real time updates, complex layouts to be mobile-friendly, real-time updates of many components, endless scrolling and PWA features would be a total PITA. Yes, I don't disagree. The vast majority of web apps I have seen so far don't need to be like that.
- agos 3y ago
  "many" might be a stretch
- arkh 3y ago
  HTMX makes me think of Mootools: small, very specialized js library.
- niutech 3y ago
  HTMX is like $().load()
shakabrah 3y ago
I learned jQuery before i learned javascript proper over a decade ago. I didn’t even really understand what i was doing was considered programming. although i’ve not touched jquery in many years, i now have a great livelihood doing something i love. Long may they live.
drakenot 3y ago
I remember when jQuery was first released. To convince my coworkers to use it, I held an internal presentation called "Don't Fear the $," where I walked through the advantages it provided.
donohoe 3y ago
In job postings for FE developers, I usually put in this line: “A healthy disdain for jQuery” This changes nothing.
- hu3 3y ago
  The filter works both ways. When I see too much emotion in engineering job posts I take it as a sign that the team is more likely to be cult driven and less likely to reasonably discuss tools in terms of trade-offs.
  - donohoe 3y ago
    Fair. In reality it usually leads to some good questions on the nature of frameworks.
- tcper 3y ago
  A job pays you 10k a week for writing jQuery code, will you refuse it?
  - agos 3y ago
    we all know that job does not exist
ent101 3y ago
I wrote puter.com using jQuery :P
- Beefin 3y ago
  this is a pretty amazing site
  - ent101 3y ago
    Thank you! Glad you liked it :)
LorenzoGood 3y ago
I feel like most of Jquery has been re implemented as browser api's anyway.
joshka 3y ago
Is jQuery the COBOL of the 2000s?
- deleted 3y ago
  [deleted]
MythTrashcan 3y ago
If most of the web didn't have a huge jQuery dependancy, we would have mostly moved on years ago.
- seattle_spring 3y ago
  I thought so too before reading these comments. I'm surprised how much people think jQuery still provides everything you need for a modern webapp. I have to step back and realize that my world has been working on millions+ LOC apps with hundreds of simultaneously committing devs, vs a lot of jQuery devs committing to personal-sized projects or blog-like web pages. Totally different solutions for different problems. I'd still pick vanilla es6+ vs jQuery for smaller stuff, but I get why some might not.
etoxin 3y ago
jQuery has mostly been replaced by new browser apis. It was a great library that brought the web forward. It will still be around the web for decades to come. If you're updating to jQuery 4. Why not try switching to native js. https://youmightnotneedjquery.com/ https://youmightnotneedjquery.com/
tored 3y ago
Worst part of jQuery is actually upgrading it to a new version, because the api design that made jQuery powerful is also what makes it quite difficult figure out if you broke anything.
- mkoryak 3y ago
  Why worry when you can easily load both versions with jQuery.noConflict() !!! Or you can just load one on top of the other. It will be ok
  - tored 3y ago
    Loading jQuery twice is a band aid solution. However the jQuery 4 announcement page linked to this jQuery migration plugin that I was unaware of. Perhaps it can help in some old projects. https://github.com/jquery/jquery-migrate https://github.com/jquery/jquery-migrate
    - mkoryak 3y ago
      I was really really joking
MangoCoffee 3y ago
Jquery made it to version 4 beta and there's a version 5 in the future. it looks like there's a big enough market for JQuery.
holoduke 3y ago
I still use it as my low level html operations lib in my framework. Its still super handy. And size wise small.
sazz 3y ago
Oh I loved jQuery. Anybody remembers DataTables https://datatables.net https://datatables.net or X-editable https://vitalets.github.io/x-editable/ https://vitalets.github.io/x-editable/ ?
- werdnapk 3y ago
  Remember? I still use DataTables.
  - bdcravens 3y ago
    Many third-party themes still package it. I've looked at alternatives, and they're either less function with way more config, or they are trying to be Excel clones.
mysteryos 3y ago
This throws me back to my junior days (2008~) where i had a heated discussion with my technical lead, to add jQuery to a project. His argument was that the size of minified library(40kb) would add too much overhead to the loading time of the page. He then, promptly spent a full week trying to code an ajax call and testing its support on different browsers and ultimately failed to make it work on Internet explorer 5. jQuery solves many headaches back then, and yes he finally added the library to the project.
- freediver 3y ago
  Kudos to your technical lead for fighting a good fight.
- sam0x17 3y ago
  Yeah people forget this a lot, browsers used to largely disagree with each other, and jQuery was the only sensible glue that could hold a codebase together in that regard
geenat 3y ago
Awesome. My problem is I've been waiting for 4.0 soooo long I ended up making my own jQuery with some key differences: * Animations, tweens, timelines use pure CSS, instead of jQuery's custom system. * Use one element or lists transparently. * Inline <script> Locality of Behavior. No more inventing unique "one time" names. * Vanilla first. Zero dependencies. 1 file. Under 340 lines. https://github.com/gnat/surreal https://github.com/gnat/surreal That said, it's fantastic to see 4.0 here, and I'll certainly be upgrading my many sites that use it!
- panphora 3y ago
  I've always thought there should be a modern, lightweight jQuery alternative like this. Well done! I love the syntax and have been implementing something similar (although with inline events and more than just the standard array methods). [0] Do you have an article/screencast on how the locality of behavior is implemented in both surreal and its companion project css-scope-inline? I'd love to understand it so I can maintain it longterm and add it to my own projects. I'd love to talk with you about your philosophy of the web. I think we could sync up about some things! [0] https://hyperspace.so/All.js.png https://hyperspace.so/All.js.png
  - niutech 3y ago
    > I've always thought there should be a modern, lightweight jQuery alternative like this. Have you heard of Zepto? https://zeptojs.com https://zeptojs.com
    - panphora 3y ago
      Yes, thank you! Zepto is great and it's nice it's jQuery compatible. I've used it before and liked it. However, I guess I was thinking something a bit more modern -- adding more advanced functionality than what jQuery has. Like more array methods for elements (e.g. `pluck` elements based on property values), reactive data stores/templating, a mutation observer helper.
      - 3y ago
ape4 3y ago
For the functions that are being removed, is there a list of the native replacements. eg $.isNumeric() == parseFloat() ?
- StayTrue 3y ago
  A guide would be nice but you can always look at the jQuery implementations. isNumeric: https://github.com/jquery/jquery/blob/bf48c21d225c31f0f9b5441d95f73615ca3dcfdb/src/core.js#L206 https://github.com/jquery/jquery/blob/bf48c21d225c31f0f9b544...
  - ape4 3y ago
    Thanks. That seems useful to keep in jQuery even though its only one line of code. So everyone doesn't have to copy and paste that non-obvious function.
lofaszvanitt 3y ago
Time to send letters to the core js standards team to ask JR for permission (plus giving him a briefcase and a deus ex machina ;)) to bring the full jQuery treatment into core JS. In order to replace the cumbersome JS things with jQuery. Why always complicate things...
timeon 3y ago
I still think that MooTools was better.
kinj28 3y ago
FWIW we built our entire low code platform drag and drop editor with jquery. This includes editor, all controls (read Ui components) and needlessly to say that even the code that it ends up generating is pure play jquery. But the execs at big corps often question our sales engineering for why not react/angular/ etc. So I am super glad to read that jquery continues to be so relevant even now. And am glad my cofounder and CTO always continued to back this rather than looked at moving the stack.
nyarlathotep_ 3y ago
Nothing to add. Just happy to see jQuery is still around. It's easy to forgot how widely used (depended on, rather?) it still is.
neycoda 3y ago
I'll still take jQuery over raw JavaScript. Much easier, more efficient, more intuitive.
wsaryoo 3y ago
Always depressed when I saw some new JS library promote "No jQuery" is one of its main features

569 points by joshmanders 3y ago

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.

dylan604 3y ago
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 back end person that has to write front end stuff because nobody else does it.
- lakpan 3y ago
  It’s only simpler because you know how to use it. For most use cases fetch and async/await is just easier.
  - dylan604 3y ago
    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?
    - umvi 3y ago
      Async await fetch lets you flatten your nested callback functions into simple procedural programming. It makes everything much easier to reason about, no more closures and such.
      - dylan604 3y ago
        see, this is where i'm not cool with this newness. i've spent years getting away from procedural, and switching to functions, classes/methods. now, we want to get away from that and go back to procedural? that's all fine and dandy, but you're trying to have a new trick conversation with an old dog that just doesn't care. you're bringing some sort of logic to a conversation where it's not needed. it works for me. i don't get paid to make UI apps or write heavy code nonsense with server side JS. i use a proper back end language. JS can stay in the browser and manipulate the DOM thank you very much. i get paid to make heavy processing code that sometimes is helpful to have UI dashboards. i can whip up a JQuery front end faster for my needs than most can even figure out what NPM librar[y|ies] they need to use
        boredtofears 3y ago
        surely you still use procedural code within your functions and classes. the point of await/async is you break down the callback nesting into a single set of procedural code. it doesn't mean all your code is procedural. just that what used to have to be a series of indented anonymous functions or spread all over the place named functions can now be an easy to read concise few lines of code all at the same indentation in a single spot. its an obvious net-win for readability and code maintainability. you are doing yourself no favors by not understanding/embracing it.
        deleted 3y ago
        [deleted]
        marcosdumay 3y ago
        > now, we want to get away from that and go back to procedural? AFAIK, we are all still programming browser UI with Javascript. It is an imperative language, about as stateful as you can get. Now, if you managed to do your frontends with Haskell or Prolog, I'd be interested on learning how.
        zdkl 3y ago
- duskwuff 3y ago
  > 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.
  - dylan604 3y ago
    you think it's the same, but it's not even close to me .ajax({ success:function(result), error:function(xhr), } vs fetch().then((e)=>function()) is even close to being the same, then we're just not even talking the same language
    - umvi 3y ago
      You would just do: const response = await fetch(...) Bam, now you have the response without needing callbacks.
      - dvt 3y ago
        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. So to get the text content of the response, I just need to do response.text, right? No, you dummy, that's a function! You need to call response.text(), duh. It's so funny how an entire generation of front-end engineers just accepted this slop as acceptable API design. You can't fix the past, but thank God for (oh the irony) Microsoft and TypeScript.
        n_plus_1_acc 3y ago
        There are many popular wrappers like axios that fix some of these things.
        3y ago
- austin-cheney 3y ago
  WebSockets are easier and faster.
kxrm 3y ago
> who is actively developing using jQuery? Yea same, I am actively trying to get rid of jQuery, but my guess would be people get used to working with a tool and there just isn't enough desire or a business case to get rid of it as it would require a rewrite. I would say that I doubt new projects are starting with jQuery but I know there are devs out there that know the jQuery way better than the vanilla javascript way to get things done.
- MBCook 3y ago
  But if you don’t want to get rid of it for business reasons, which I get, a major upgrade that changes a bunch of APIs and drops features would still require a lot of work. And if you’re forced to leave 3.x over security or something (may happen in the future) then why not just move off then?
  - dylan604 3y ago
    I'd imagine upgrading from JQuery 3.x to 4.0 will be much less hassle than starting from essentially a blank page even if you were using some of the deprecated methods (even though you've previously been warned).
  - kxrm 3y ago
    Yea, see the last half of my comment. There is a lot of legacy knowledge around how jQuery handles things and there are devs out there who just aren't interested in learning how to do it without jQuery. For their customers and users, it makes no difference.
lawgimenez 3y ago
Based on last year’s Stack survey, JQuery is the third popular. https://survey.stackoverflow.co/2023/#section-most-popular-technologies-web-frameworks-and-technologies https://survey.stackoverflow.co/2023/#section-most-popular-t...
- notso411 3y ago
  [dead]
sublinear 3y ago
There are plenty of legacy web projects still using jQuery that nobody has been able to replace. Off the top of my head I'm thinking of complex boring stuff like WCAG-compliant carousels or whatever. The kind of libraries people tend to reach for because marketing wanted them, but are otherwise ignored.
ahmedfromtunis 3y ago
Django uses jQuery for its admin interface. (That is, jQuery is used by the Django maintainers to write the built-in admin interface.) But I also know that a lot of the "low-cost" agencies are still using it. Probably because de the devs are used to using and don't want to bother to (re)learn things. At least in my country, a lot of website are still using it (and very old, outdated versions at that).
arp242 3y ago
The DOM API now solves a lot of the issues jQuery solved 15 years ago, but often in very different ways. I don't think it's better; a lot of the APIs are awkwardly designed IMO. The big upshot is that it's built-in, but that's it, and with a very small jQuery library you get a nicer API. Sometimes the extra dependency is best avoided, but often it doesn't matter. So, whenever reasonable, I prefer to just add jQuery. Maybe there's something better, but the differences/improvements of what I've seen doesn't seem that great and jQuery works, so that's the point? I guess the younger kids never used it, but it's easy enough to pick up if you know standard JS.
sam0x17 3y ago
It's funny, I just spent a bunch of time removing the last vestiges of react for a company, replacing it with HTMX, which imo is the spiritual successor to jQuery in some ways
mhitza 3y ago
I wouldn't exclude the possibility of new developers that found some stackoverflow answer, or another, which suggests jQuery as the solution.
miragecraft 3y ago
jQuery is still excellent if you are creating websites (not web apps) with minimal JavaScript.
deleted 3y ago
[deleted]
mrieck 3y ago
Solo or small team devs who hate modern tooling. Good example is levelsio guy: https://twitter.com/levelsio/status/1750175827197567165 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 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
gexla 3y ago
I'm guessing most active development which people are actually consuming. Already mentioned is Wordpress, which is most of the web. There's probably tons of front-ends using old Bootstrap which also came with Jquery. Greenfield projects might not be using Jquery, but is anyone actually using those? ;)
AdrianB1 3y ago
I am using it when I need AJAX + Datatables for quick, but not dirty pages showing data in different ways that takes minutes to set up. Actually my projects are native JS for most and jQuery for that specific combination above. These are not public or commercial apps, just internal use for my department. I am not even a developer by role, but I build stuff when needed and time allows it.

OccamsMirror 3y ago

With browsers having much better support with DOM selection, why would anyone be using jQuery in 2024? Not trying to throw shade, I actually think it's cool that it's still being worked on. But I'm confused as to what the use case is.

anamexis 3y ago
If I had to guess, a convenient API and a massive ecosystem.
arp242 3y ago
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 more fluently.
- evan_ 3y ago
  `:visible` and `:hidden` are really cool
  - senfiaj 3y ago
    In my opinion selecting something based on it's layout is oftentimes a dangerous pattern, you are basically tying the UI layout with the logic. People can overuse these cool selectors. I've personally worked on a website where the frontend part was a spaghetti mess with the half of the source code occupied by selector names. Some files have over 5000 lines of code. It would be far less pain to maintain and implement features if the website used some framework like angular.
- mkl 3y ago
  :checked is standard CSS, and old.

jszymborski 3y ago

Bring yayQuery back. The people demand it.

technojunkie 3y ago

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.

ecshafer 3y ago
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 this simplicity with htmx, phoenix live view, ruby on rails turbo, and yes just jQuery.
- bufferoverflow 3y ago
  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.
  - rjbwork 3y ago
    >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.
    - auxfil 3y ago
      [dead]

synergy20 3y ago

Most elegant API for Javascript, can it become part of Javascript API directly one day?

didip 3y ago

Great job jQuery folks! I will forever love jQuery. It simply gets the job done.

5350-uiop-1130 3y ago
Bootstrap, PHP, JQuery & WP. The stack for people who get shit done.

ActualHacker 3y ago

I was evaluating a SaaS solution just yesterday, and in one of their examples on Github they used jQuery as the primary frontend for the project, with extensive usage. I passed on the company

jraph 3y ago
Why? What's wrong, if it works well?
- paulddraper 3y ago
  There are things that work better.
  - jraph 3y ago
    Seems a weak reason for rejecting a solution and this is subjective. I prefer native JS but something can be well designed in jQuery.
  - wiseowise 3y ago
    Define “better”.
    - paulddraper 3y ago
      More succinct, fewer bugs.
kmoser 3y ago
With SaaS, the front end might be the least important piece of the application.
cynicalsecurity 3y ago
Too bad for you. I'm glad for them they don't have to deal with you as a customer.

wkirby 3y ago

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 needs a little enhancement on top of server-side HTML, but not a full-blown JS UI framework, jQuery is a small price to pay for a stable, reliable, and cross-browser compatible dependency.

genocidicbunny 3y ago
I don't think it's that surprising given the demographics of HN posters that I've observed. Many will immediately reach for the big JS framework du jour when they need anything more than a little DOM selection stuff, because that's what they've always done.
- erhaetherth 3y ago
  There's 2 types of web pages. Websites and web apps. If you're building a web app, you're going to want a framework that isn't going to fall apart the second things start getting complicated. If you're making a little marketing website, sure, sprinkle some jQuery on there and call it a day. Probably better for performance and SEO unless you want to spend 10x as long micro-optimizing your SSR. Point is, there's different use-cases.
  - genocidicbunny 3y ago
    Okay, what part of what I said are you trying to refute or educate me on? There's a large proportion of posters on HN who spend their days building web apps. They are very likely to stick to using what they know, even when building web sites. If you spend your days working as a welder, and suddenly need to build a box for some reason, you're probably not going to be breaking out the fine wood joinery tools. You're probably going to take some sheet steel and weld up a box and move on to whatever else you have to do. It's not a problem, it's not a fault, it just how things are.

nfriedly 3y ago

I remember building web apps in the days before jQuery, it was a mess. The DOM APIs were full of quirks, and all the libraries that predated jQuery had their own issues. These days, we have better options for building complex web apps, including much-improved native APIs. I don't think I've started a new project using jQuery in 10 years. But for maintainin a lightweight website that just needs a little bit of interaction or pizzazz, I still think jQuery is perfectly fine.

yread 3y ago
Especially the events! Those were browser-specific nightmares
- senfiaj 3y ago
  Today it's not nearly as bad as it was before. I personally have very few reasons to use jQuery. Maybe it's somewhat shorter code and supports some cool pseudoselectors (IMHO, they are often bad patterns) but for me it's often easier to understand and debug a code using vanilla JS. For example, sometimes I have struggled to find the exact event listener callback by using dev tools because when you use nested click events because the code passes throw a lot of jQuery code before reaching the actual event listener.

andirk 3y ago

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.

notzane 3y ago
Doesn’t work anymore :( https://news.ycombinator.com/item?id=24894135 https://news.ycombinator.com/item?id=24894135
- andirk 3y ago
  Wow! I'm embarrassed I didn't know this since 2020. Too bad we can't allow certain super popular libraries of whose project maintainers we trust to still be cached across domains.
deleted 3y ago
[deleted]
nsp 3y ago
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-caching-across-sites-and-domains/ https://www.stefanjudis.com/notes/say-goodbye-to-resource-ca...
- lenkite 3y ago
  This feels like it is still pretty good when you are on a common host like github pages.

mholt 3y ago

I loved jQuery. Still great, but browser APIs have improved. Now I mainly use AJQuery: https://github.com/coolaj86/ajquery.js/blob/main/ajquery.js https://github.com/coolaj86/ajquery.js/blob/main/ajquery.js

DonnyV 3y ago

A lot of what jQuery was created to do is now baked into the browser. CSS selectors, proper ajax, animation, etc. I built a small convenience library around fetch to make it super easy to use ajax like in jQuery. Also built a small utility library around ES6 methods that recreate jQuery methods. It doesn't take much to get back the convenience of jQuery but still use all the new tools. I love jQuery and used it for years. But there are better tools now.

hallman76 3y ago

Just in case folks aren't familiar, this site breaks down jQuery features into web standard code: https://youmightnotneedjquery.com/ https://youmightnotneedjquery.com/

voat 3y ago

Another day another JavaScript framework! I'm so tired of all this churn in frontend. /s

mm007emko 3y ago

I remember jQuery from it's heyday when we used it as a replacement for Mootools. Since many people are going from React to HTMX, maybe we've made a full circle and we'll see web using just plain jQuery as well?

evilduck 3y ago
I came up in a similar era, I don’t think back fondly on those messes. Doing a modern app with accessibility, mobile support, real time updates, visualizations, and maybe a few PWA features with just jQuery sounds incredibly unpleasant. I’m waiting for the HTMX hype train to meet reality too. Programming your app in pseudo attributes with a DSL is going to wear thin quickly.
- mm007emko 3y ago
  I think that many websites even nowadays don't need all that jazz and many would improve if less JavaScript was on them. How many times have you loaded a website only to watch a couple of JavaScript "spinners" for everything to load only to click somewhere and everything started again? MS Azure management is one of such sites. SPA with real time updates, complex layouts to be mobile-friendly, real-time updates of many components, endless scrolling and PWA features would be a total PITA. Yes, I don't disagree. The vast majority of web apps I have seen so far don't need to be like that.
agos 3y ago
"many" might be a stretch
arkh 3y ago
HTMX makes me think of Mootools: small, very specialized js library.
niutech 3y ago
HTMX is like $().load()

shakabrah 3y ago

I learned jQuery before i learned javascript proper over a decade ago. I didn’t even really understand what i was doing was considered programming. although i’ve not touched jquery in many years, i now have a great livelihood doing something i love. Long may they live.

drakenot 3y ago

I remember when jQuery was first released. To convince my coworkers to use it, I held an internal presentation called "Don't Fear the $," where I walked through the advantages it provided.

donohoe 3y ago

In job postings for FE developers, I usually put in this line: “A healthy disdain for jQuery” This changes nothing.

hu3 3y ago
The filter works both ways. When I see too much emotion in engineering job posts I take it as a sign that the team is more likely to be cult driven and less likely to reasonably discuss tools in terms of trade-offs.
- donohoe 3y ago
  Fair. In reality it usually leads to some good questions on the nature of frameworks.
tcper 3y ago
A job pays you 10k a week for writing jQuery code, will you refuse it?
- agos 3y ago
  we all know that job does not exist

ent101 3y ago

I wrote puter.com using jQuery :P

Beefin 3y ago
this is a pretty amazing site
- ent101 3y ago
  Thank you! Glad you liked it :)

LorenzoGood 3y ago

I feel like most of Jquery has been re implemented as browser api's anyway.

joshka 3y ago

Is jQuery the COBOL of the 2000s?

deleted 3y ago
[deleted]

MythTrashcan 3y ago

If most of the web didn't have a huge jQuery dependancy, we would have mostly moved on years ago.

seattle_spring 3y ago
I thought so too before reading these comments. I'm surprised how much people think jQuery still provides everything you need for a modern webapp. I have to step back and realize that my world has been working on millions+ LOC apps with hundreds of simultaneously committing devs, vs a lot of jQuery devs committing to personal-sized projects or blog-like web pages. Totally different solutions for different problems. I'd still pick vanilla es6+ vs jQuery for smaller stuff, but I get why some might not.

etoxin 3y ago

jQuery has mostly been replaced by new browser apis. It was a great library that brought the web forward. It will still be around the web for decades to come. If you're updating to jQuery 4. Why not try switching to native js. https://youmightnotneedjquery.com/ https://youmightnotneedjquery.com/

tored 3y ago

Worst part of jQuery is actually upgrading it to a new version, because the api design that made jQuery powerful is also what makes it quite difficult figure out if you broke anything.

mkoryak 3y ago
Why worry when you can easily load both versions with jQuery.noConflict() !!! Or you can just load one on top of the other. It will be ok
- tored 3y ago
  Loading jQuery twice is a band aid solution. However the jQuery 4 announcement page linked to this jQuery migration plugin that I was unaware of. Perhaps it can help in some old projects. https://github.com/jquery/jquery-migrate https://github.com/jquery/jquery-migrate
  - mkoryak 3y ago
    I was really really joking

MangoCoffee 3y ago

Jquery made it to version 4 beta and there's a version 5 in the future. it looks like there's a big enough market for JQuery.

holoduke 3y ago

I still use it as my low level html operations lib in my framework. Its still super handy. And size wise small.

sazz 3y ago

Oh I loved jQuery. Anybody remembers DataTables https://datatables.net https://datatables.net or X-editable https://vitalets.github.io/x-editable/ https://vitalets.github.io/x-editable/ ?

werdnapk 3y ago
Remember? I still use DataTables.
- bdcravens 3y ago
  Many third-party themes still package it. I've looked at alternatives, and they're either less function with way more config, or they are trying to be Excel clones.

mysteryos 3y ago

This throws me back to my junior days (2008~) where i had a heated discussion with my technical lead, to add jQuery to a project. His argument was that the size of minified library(40kb) would add too much overhead to the loading time of the page. He then, promptly spent a full week trying to code an ajax call and testing its support on different browsers and ultimately failed to make it work on Internet explorer 5. jQuery solves many headaches back then, and yes he finally added the library to the project.

freediver 3y ago
Kudos to your technical lead for fighting a good fight.
sam0x17 3y ago
Yeah people forget this a lot, browsers used to largely disagree with each other, and jQuery was the only sensible glue that could hold a codebase together in that regard

geenat 3y ago

Awesome. My problem is I've been waiting for 4.0 soooo long I ended up making my own jQuery with some key differences: * Animations, tweens, timelines use pure CSS, instead of jQuery's custom system. * Use one element or lists transparently. * Inline <script> Locality of Behavior. No more inventing unique "one time" names. * Vanilla first. Zero dependencies. 1 file. Under 340 lines. https://github.com/gnat/surreal https://github.com/gnat/surreal That said, it's fantastic to see 4.0 here, and I'll certainly be upgrading my many sites that use it!

panphora 3y ago
I've always thought there should be a modern, lightweight jQuery alternative like this. Well done! I love the syntax and have been implementing something similar (although with inline events and more than just the standard array methods). [0] Do you have an article/screencast on how the locality of behavior is implemented in both surreal and its companion project css-scope-inline? I'd love to understand it so I can maintain it longterm and add it to my own projects. I'd love to talk with you about your philosophy of the web. I think we could sync up about some things! [0] https://hyperspace.so/All.js.png https://hyperspace.so/All.js.png
- niutech 3y ago
  > I've always thought there should be a modern, lightweight jQuery alternative like this. Have you heard of Zepto? https://zeptojs.com https://zeptojs.com
  - panphora 3y ago
    Yes, thank you! Zepto is great and it's nice it's jQuery compatible. I've used it before and liked it. However, I guess I was thinking something a bit more modern -- adding more advanced functionality than what jQuery has. Like more array methods for elements (e.g. `pluck` elements based on property values), reactive data stores/templating, a mutation observer helper.
    - 3y ago

ape4 3y ago

For the functions that are being removed, is there a list of the native replacements. eg $.isNumeric() == parseFloat() ?

StayTrue 3y ago
A guide would be nice but you can always look at the jQuery implementations. isNumeric: https://github.com/jquery/jquery/blob/bf48c21d225c31f0f9b5441d95f73615ca3dcfdb/src/core.js#L206 https://github.com/jquery/jquery/blob/bf48c21d225c31f0f9b544...
- ape4 3y ago
  Thanks. That seems useful to keep in jQuery even though its only one line of code. So everyone doesn't have to copy and paste that non-obvious function.

lofaszvanitt 3y ago

Time to send letters to the core js standards team to ask JR for permission (plus giving him a briefcase and a deus ex machina ;)) to bring the full jQuery treatment into core JS. In order to replace the cumbersome JS things with jQuery. Why always complicate things...

timeon 3y ago

I still think that MooTools was better.

kinj28 3y ago

FWIW we built our entire low code platform drag and drop editor with jquery. This includes editor, all controls (read Ui components) and needlessly to say that even the code that it ends up generating is pure play jquery. But the execs at big corps often question our sales engineering for why not react/angular/ etc. So I am super glad to read that jquery continues to be so relevant even now. And am glad my cofounder and CTO always continued to back this rather than looked at moving the stack.

nyarlathotep_ 3y ago

Nothing to add. Just happy to see jQuery is still around. It's easy to forgot how widely used (depended on, rather?) it still is.

neycoda 3y ago

I'll still take jQuery over raw JavaScript. Much easier, more efficient, more intuitive.

wsaryoo 3y ago

Always depressed when I saw some new JS library promote "No jQuery" is one of its main features