5 ms·

I'm aware of "You might not need jQuery", but has anyone created a comprehensive list of everything jQuery offers that is not available through native JS/CSS?

I'm aware of "You might not need jQuery", but has anyone created a comprehensive list of everything jQuery offers that is not available through native JS/CSS? I guess I should specify, not available as easy as jQuery. Technically anything that jQuery does can, obviously, be done natively, but I remember there were some things that were much much much easier to do in jQuery than natively. Some of those easy patterns have been adopted into native, but surely not everything.

whatshisface 4y ago
It has changed a lot over time. Now native JS even has query selectors!
- simion314 4y ago
  Still not all selectors that are in jQuery , I think :header is not yet native, not the selectors by attribute value.
  - robgibbons 4y ago
    You can select by attribute value. Even "starts with" selectors eg: document.querySelectorAll('[name^="starts-with-this"]') or "containing" selectors: document.querySelectorAll('[name*="contains-this"]')
  - lycos 4y ago
    I believe querySelector/querySelectorAll supports all native CSS selectors, including attribute selectors. But jQuery does hahve custom selectors as well (at least last I used it, which is over 10 years ago)
bastawhiz 4y ago
Anything involving multiple elements in a single operation. $('.foo').hide() requires something silly like Array.from(document.querySelectorAll('.foo')).forEach(el => el.style.display = 'none'); Being able to select something, then chain operations on those nodes is really where jQuery shines, IMO. All of the non-DOM stuff (e.g., AJAX) is fine with vanilla JS these days.
- bufferoverflow 4y ago
  You don't need Array.from this works fine: document.querySelectorAll('.age').forEach(el => el.style.display = 'none') But I didn't have to do anything like that in years. With reactive frameworks you just bind visibility and styles to variables, refs or some central state.
  - Spivak 4y ago
    I think that was to handle older browsers. https://caniuse.com/mdn-api_nodelist_foreach https://caniuse.com/mdn-api_nodelist_foreach looks pretty good but it didn't used to.
    - deleted 4y ago
      [deleted]
  - tambourine_man 4y ago
    > With reactive frameworks you just bind visibility and styles to variables, refs or some central state I fail to see the superiority of that approach after more than a decade. To me, the success of React and the likes has more to do with team dynamics, hiring, etc.
    - bufferoverflow 4y ago
      I easily see the superiority. The data controls the UI, instead of some random line of code that's very hard to find. Essentially it's declarative programming, you declare your UI should look this way when the state is this, and that way when the state is that. It's much easier to reason about than when you have a thousand random functions that can change the UI, often in ways that break each other.
      - tambourine_man 4y ago
        That’s what I meant by team dynamics. I can separate concerns instead of multiple functions changing the same UI, but I can’t guarantee that everyone else will. The conventions that React provides sidesteps the need for discipline and that I find useful. Doesn’t mean that the approach in itself is better, IMO. and if you work alone, it’s clearly way too much trouble for little gain.
hinkley 4y ago
Once upon a time someone asked me this question, and it lead me back to my only real complaint about jQuery, and a momentary urge to create a smaller version with a few behavioral differences. The CSS selector bit was always the strongest portion to me. Getting that into your project allows you to get more work and involvement in the system from your 'just a frontend person' people, and reluctant backend people working on the UI. Add to this the ability to apply CSS selectors to your ancestors, which has been lacking from DOM for far, far too long. But the last leg of that stool is the list comprehension semantics. Being able to implement "select all" or "clear all checkboxes" in one line of code. The only problem with this functionality is that it fails silently on a bad or out-of-date selector, and I think that was a mistake, but one that is hard to fix in retrospect without creating another library with different defaults. I think by default that such a call should fail, with an override for that 1 in 20 case where you just don't care. I'd also like to see either fewer frameworks or more frameworks that have thin veneers over common libraries, like jQuery. People underestimate the psychological safety people get from feeling that they could leave a job or ecosystem whenever they want. We behave as if stuckness leads to complacency, but your best coworkers see complacency as a warning, and will choose half-considered actions (like jumping ship) as a viable alternative to the status quo. People who get unstuck can become your enemy instead of just an ex-user as well, feeling they need to 'rescue' others from your dirty clutches. The following is more stream of consciousness than something I've thought about, so someone who has thought about it longer can probably clever out a good answer. In later versions it's tried harder not to get itself into reflow loops, but since I'm not an active user anymore, I don't know if that's so much a standalone feature as it is fixing bugs in the abstraction. There's probably other ways to fix such problems too, something more like zip() semantics, where you take a selector, run all of the get() operations, look at the answers, and only then mutate the list. Perhaps there's a two argument API in there, or maybe a fluent interface would flow better.
neilpanchal 4y ago
We still use jQuery + jQuery UI on our website because it is basically battle tested through 15+ years. https://jqueryui.com/ https://jqueryui.com/ It is easy as hell. What's there to not like? I don't care to be called names or being old fashioned. I also don't care about "right" tooling for frontend. As far as it works, it is robust and it is going to be around for many years, I am fine with it.
- no_wizard 4y ago
  The JS Foundation oversees the jQuery project as a steward and has it listed as "end of life or near end of life" for jQuery UI. I'd suggest for bug fixes & security updates to quite likely look elsewhere [0]: https://openjsf.org/projects/ https://openjsf.org/projects/
  - yread 4y ago
    bug fixes & security updates? That's the beauty of jQuery: you don't need those. It's done
  - jmholla 4y ago
    I don't think jQuery UI's move into maintenance mode is not that much of a concern. They are not the only clients. The foundation lists jQuery under its Impact Projects which are described as: > Impact projects are on a sustaining cycle of development, maintenance, and long-term support. These projects are used commonly in enterprise production environments and have large, well-established project communities. > ... > They receive ongoing financial and marketing support from the Foundation, and are expected to cross-promote the foundation along with their activities. This seems to me like they expect to continue to support jQuery for the foreseeable future.
brudgers 4y ago
Jquery runs existing jquery code, and people who have written jquery code for many years can leverage their expertise and experience.
progmetaldev 4y ago
I think if you understand the inner workings or jQuery, it's still nice to chain multiple operations together and keep your user code smaller than pure JS. It's also helpful that so many devs have become familiar with jQuery over time, rather than bringing on someone that needs to parse all of your vanilla JS (everyone seems to have their own way of doing things).

whatshisface 4y ago

It has changed a lot over time. Now native JS even has query selectors!

simion314 4y ago
Still not all selectors that are in jQuery , I think :header is not yet native, not the selectors by attribute value.
- robgibbons 4y ago
  You can select by attribute value. Even "starts with" selectors eg: document.querySelectorAll('[name^="starts-with-this"]') or "containing" selectors: document.querySelectorAll('[name*="contains-this"]')
- lycos 4y ago
  I believe querySelector/querySelectorAll supports all native CSS selectors, including attribute selectors. But jQuery does hahve custom selectors as well (at least last I used it, which is over 10 years ago)

bastawhiz 4y ago

Anything involving multiple elements in a single operation. $('.foo').hide() requires something silly like Array.from(document.querySelectorAll('.foo')).forEach(el => el.style.display = 'none'); Being able to select something, then chain operations on those nodes is really where jQuery shines, IMO. All of the non-DOM stuff (e.g., AJAX) is fine with vanilla JS these days.

bufferoverflow 4y ago
You don't need Array.from this works fine: document.querySelectorAll('.age').forEach(el => el.style.display = 'none') But I didn't have to do anything like that in years. With reactive frameworks you just bind visibility and styles to variables, refs or some central state.
- Spivak 4y ago
  I think that was to handle older browsers. https://caniuse.com/mdn-api_nodelist_foreach https://caniuse.com/mdn-api_nodelist_foreach looks pretty good but it didn't used to.
  - deleted 4y ago
    [deleted]
- tambourine_man 4y ago
  > With reactive frameworks you just bind visibility and styles to variables, refs or some central state I fail to see the superiority of that approach after more than a decade. To me, the success of React and the likes has more to do with team dynamics, hiring, etc.
  - bufferoverflow 4y ago
    I easily see the superiority. The data controls the UI, instead of some random line of code that's very hard to find. Essentially it's declarative programming, you declare your UI should look this way when the state is this, and that way when the state is that. It's much easier to reason about than when you have a thousand random functions that can change the UI, often in ways that break each other.
    - tambourine_man 4y ago
      That’s what I meant by team dynamics. I can separate concerns instead of multiple functions changing the same UI, but I can’t guarantee that everyone else will. The conventions that React provides sidesteps the need for discipline and that I find useful. Doesn’t mean that the approach in itself is better, IMO. and if you work alone, it’s clearly way too much trouble for little gain.

hinkley 4y ago

Once upon a time someone asked me this question, and it lead me back to my only real complaint about jQuery, and a momentary urge to create a smaller version with a few behavioral differences. The CSS selector bit was always the strongest portion to me. Getting that into your project allows you to get more work and involvement in the system from your 'just a frontend person' people, and reluctant backend people working on the UI. Add to this the ability to apply CSS selectors to your ancestors, which has been lacking from DOM for far, far too long. But the last leg of that stool is the list comprehension semantics. Being able to implement "select all" or "clear all checkboxes" in one line of code. The only problem with this functionality is that it fails silently on a bad or out-of-date selector, and I think that was a mistake, but one that is hard to fix in retrospect without creating another library with different defaults. I think by default that such a call should fail, with an override for that 1 in 20 case where you just don't care. I'd also like to see either fewer frameworks or more frameworks that have thin veneers over common libraries, like jQuery. People underestimate the psychological safety people get from feeling that they could leave a job or ecosystem whenever they want. We behave as if stuckness leads to complacency, but your best coworkers see complacency as a warning, and will choose half-considered actions (like jumping ship) as a viable alternative to the status quo. People who get unstuck can become your enemy instead of just an ex-user as well, feeling they need to 'rescue' others from your dirty clutches. The following is more stream of consciousness than something I've thought about, so someone who has thought about it longer can probably clever out a good answer. In later versions it's tried harder not to get itself into reflow loops, but since I'm not an active user anymore, I don't know if that's so much a standalone feature as it is fixing bugs in the abstraction. There's probably other ways to fix such problems too, something more like zip() semantics, where you take a selector, run all of the get() operations, look at the answers, and only then mutate the list. Perhaps there's a two argument API in there, or maybe a fluent interface would flow better.

neilpanchal 4y ago

We still use jQuery + jQuery UI on our website because it is basically battle tested through 15+ years. https://jqueryui.com/ https://jqueryui.com/ It is easy as hell. What's there to not like? I don't care to be called names or being old fashioned. I also don't care about "right" tooling for frontend. As far as it works, it is robust and it is going to be around for many years, I am fine with it.

no_wizard 4y ago
The JS Foundation oversees the jQuery project as a steward and has it listed as "end of life or near end of life" for jQuery UI. I'd suggest for bug fixes & security updates to quite likely look elsewhere [0]: https://openjsf.org/projects/ https://openjsf.org/projects/
- yread 4y ago
  bug fixes & security updates? That's the beauty of jQuery: you don't need those. It's done
- jmholla 4y ago
  I don't think jQuery UI's move into maintenance mode is not that much of a concern. They are not the only clients. The foundation lists jQuery under its Impact Projects which are described as: > Impact projects are on a sustaining cycle of development, maintenance, and long-term support. These projects are used commonly in enterprise production environments and have large, well-established project communities. > ... > They receive ongoing financial and marketing support from the Foundation, and are expected to cross-promote the foundation along with their activities. This seems to me like they expect to continue to support jQuery for the foreseeable future.

brudgers 4y ago

Jquery runs existing jquery code, and people who have written jquery code for many years can leverage their expertise and experience.

progmetaldev 4y ago

I think if you understand the inner workings or jQuery, it's still nice to chain multiple operations together and keep your user code smaller than pure JS. It's also helpful that so many devs have become familiar with jQuery over time, rather than bringing on someone that needs to parse all of your vanilla JS (everyone seems to have their own way of doing things).