5 ms·

Yes. Technically you could always use native JS in place of jQuery and have the same functionality. But jQuery's power came from abstracting away some of the me

Yes. Technically you could always use native JS in place of jQuery and have the same functionality. But jQuery's power came from abstracting away some of the messier and more complicated elements and giving developers a more intuitive set of tools. Some part of this are less necessary today than when jQuery v1 came out (like `querySelectorAll()` vs `$()`), but other parts are still enormously helpful (like `$.ajax()`). So like always, it's a trade off. But it's still one that comes up as worth it as often as not.

udp 4y ago
I’m not sure $.ajax() is a good example now that fetch is widely supported.
gabereiser 4y ago
`$.ajax()` has been replaced entirely by `fetch()` [0]. The only remaining use-case I can see for jquery is the animation capabilities but even that can be replaced with animejs [1]. [0] https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U... [1] https://animejs.com/ https://animejs.com/
- amflare 4y ago
  That's only mostly true. If you are working with anything that needs to support older browsers (which, for example, is unfortunately still a requirement in many medical, government, and financial sectors), then you can't use `fetch()`.
  - duskwuff 4y ago
    You can polyfill fetch() if that's a concern: https://github.com/github/fetch https://github.com/github/fetch
  - no_way 4y ago
    You can use fetch polyfill which woyld be better choice since its easier to remove polyfill than refactor your whole site once you don't need to support those old browsers anymore.
    - amflare 4y ago
      Sure. I could also pull in axios or just bite the bullet and use the XMLHttpRequest API. The point isn't that jQuery is the only way to solve the problem, but rather that it still has a value proposition.
      - LudwigNagasena 4y ago
        Being a “polyfill” with idiosyncratic API doesn’t sound like a good value proposition.
  - LudwigNagasena 4y ago
    Babel?
- Beltalowda 4y ago
  I tried using fetch(). I naïvely passed an object as the POST form parameter and it sent the string "[object Object]" to the server as POST data. Apparently you need to use some special object type. Why doesn't the universal key/value type work for passing a key/values? Who knows – maybe there's a good reason, maybe not. I do know that sending [object Object] is literally never what anyone could possibly want and that almost any other design choice would be less idiotic. So I just use xmlHttpRequest or jQuery.ajax(). xmlHttpRequest is kind of awkward, but it's straight-forward and you don't get nonsense like this. I also don't care much for promises, and fetch is pretty promise-heavy.
  - gabereiser 4y ago
    You tried using fetch() without looking at the documentation on how it's supposed to be used? It's pretty clear [0]. You are supposed to JSON stringify your JSON payload so it can be attached to the body (as a string). The reason being that the browser isn't responsible for determining what goes into the request, only that you can make one. JSON isn't the only option. It could be YAML. It could be base64. It could be null. [0] https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U...
    - Beltalowda 4y ago
      It's not clear that it will do something completely idiotic if you mess up a parameter. The documentation didn't mention it, so I figured I'd try and see what happens. This is the worst of dynamic languages: if you mess something up and you get an error: okay, fair. If you mess something up and you ignore it or do something insane: that's just stupid. "Read the documentation from cover to cover to something as simple as sending a HTTP request" isn't really much of solution. > The reason being that the browser isn't responsible for determining what goes into the request, only that you can make one. JSON isn't the only option. It could be YAML. It could be base64. It could be null. The standard data type for POST is form data, so it could just default to that for objects. Or it could throw an error. Sending [object Object] is not reasonable behaviour in any shape or form. I guess it just calls the JS "to string" logic ("logic"), but spreading that to new APIs is just not a good design, especially when it's "hidden".
- runarberg 4y ago
  CSS animations and the Web Animation API are also quite nice to use and quite powerful. https://developer.mozilla.org/en-US/docs/Web/API/Web_Animations_API https://developer.mozilla.org/en-US/docs/Web/API/Web_Animati...
ssl232 4y ago
Is jQuery able to use native browser functions internally if they're available? If so then there's probably not much of a penalty over using pure JavaScript, but a large benefit from the mature component ecosystem.

udp 4y ago

I’m not sure $.ajax() is a good example now that fetch is widely supported.

gabereiser 4y ago

`$.ajax()` has been replaced entirely by `fetch()` [0]. The only remaining use-case I can see for jquery is the animation capabilities but even that can be replaced with animejs [1]. [0] https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U... [1] https://animejs.com/ https://animejs.com/

amflare 4y ago
That's only mostly true. If you are working with anything that needs to support older browsers (which, for example, is unfortunately still a requirement in many medical, government, and financial sectors), then you can't use `fetch()`.
- duskwuff 4y ago
  You can polyfill fetch() if that's a concern: https://github.com/github/fetch https://github.com/github/fetch
- no_way 4y ago
  You can use fetch polyfill which woyld be better choice since its easier to remove polyfill than refactor your whole site once you don't need to support those old browsers anymore.
  - amflare 4y ago
    Sure. I could also pull in axios or just bite the bullet and use the XMLHttpRequest API. The point isn't that jQuery is the only way to solve the problem, but rather that it still has a value proposition.
    - LudwigNagasena 4y ago
      Being a “polyfill” with idiosyncratic API doesn’t sound like a good value proposition.
- LudwigNagasena 4y ago
  Babel?
Beltalowda 4y ago
I tried using fetch(). I naïvely passed an object as the POST form parameter and it sent the string "[object Object]" to the server as POST data. Apparently you need to use some special object type. Why doesn't the universal key/value type work for passing a key/values? Who knows – maybe there's a good reason, maybe not. I do know that sending [object Object] is literally never what anyone could possibly want and that almost any other design choice would be less idiotic. So I just use xmlHttpRequest or jQuery.ajax(). xmlHttpRequest is kind of awkward, but it's straight-forward and you don't get nonsense like this. I also don't care much for promises, and fetch is pretty promise-heavy.
- gabereiser 4y ago
  You tried using fetch() without looking at the documentation on how it's supposed to be used? It's pretty clear [0]. You are supposed to JSON stringify your JSON payload so it can be attached to the body (as a string). The reason being that the browser isn't responsible for determining what goes into the request, only that you can make one. JSON isn't the only option. It could be YAML. It could be base64. It could be null. [0] https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U...
  - Beltalowda 4y ago
    It's not clear that it will do something completely idiotic if you mess up a parameter. The documentation didn't mention it, so I figured I'd try and see what happens. This is the worst of dynamic languages: if you mess something up and you get an error: okay, fair. If you mess something up and you ignore it or do something insane: that's just stupid. "Read the documentation from cover to cover to something as simple as sending a HTTP request" isn't really much of solution. > The reason being that the browser isn't responsible for determining what goes into the request, only that you can make one. JSON isn't the only option. It could be YAML. It could be base64. It could be null. The standard data type for POST is form data, so it could just default to that for objects. Or it could throw an error. Sending [object Object] is not reasonable behaviour in any shape or form. I guess it just calls the JS "to string" logic ("logic"), but spreading that to new APIs is just not a good design, especially when it's "hidden".
runarberg 4y ago
CSS animations and the Web Animation API are also quite nice to use and quite powerful. https://developer.mozilla.org/en-US/docs/Web/API/Web_Animations_API https://developer.mozilla.org/en-US/docs/Web/API/Web_Animati...

ssl232 4y ago

Is jQuery able to use native browser functions internally if they're available? If so then there's probably not much of a penalty over using pure JavaScript, but a large benefit from the mature component ecosystem.