6 ms·

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 th

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.

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.