5 ms·

Tangential, but sometimes I see people say that jQuery is dead/failed. While it's not as popular anymore, I think that's actually the perfect evolution for it.

by jjice 4y ago

Tangential, but sometimes I see people say that jQuery is dead/failed. While it's not as popular anymore, I think that's actually the perfect evolution for it. jQuery was making up for browser API shortcomings, and now many of those shortcomings have been addressed and been incorporated into browser APIs (not everything, but quite a bit).

dgb23 4y ago
I agree. Also reminds me of CSS resets, the goal of modern-normalize is to make itself obsolete.
SemanticStrengh 4y ago
I really don't get this discourse, jQuery API is much more ergonomic, concise and clearer than the DOM api. Sure you can do it but that doesn't mean you should
- threatofrain 4y ago
  Ad hoc manipulation of the DOM contradicts the philosophy of a lot of frameworks, as that is state which is unaccounted for.
- pastor_bob 4y ago
  Just replace that one liner with a 15 liner.
  - LNSY 4y ago
    document.querySelector('html') And for React: https://javascript.info/custom-elements https://javascript.info/custom-elements
    - mejutoco 4y ago
      Other functions are much more difficult to replace $('.sth').closest('ul') To me jQuery is like Regex or Linq. I think it had a really good api.
      - frosted-flakes 4y ago
        You can also do this with DOM APIs, no? https://developer.mozilla.org/en-US/docs/Web/API/Element/closest https://developer.mozilla.org/en-US/docs/Web/API/Element/clo...
        augusto-moura 4y ago
        Is not the same thing as it is a Element method, not NodeList one, so you will would need to map it instead. Because NodeList doesn't have the .map method you would also need to transform it to a Array first. So the actually drop-in replacement of `$(foo).closest(bar)` would be something like: Array.from(document.querySelector(foo)).map(el => el.closest(bar))
        mejutoco 4y ago
        This did not exist the last time I looked. TIL. Thank you!
      - CraigJPerry 4y ago
        Is it harder or just a bit longer-winded? E.g. i'm thinking this is the same behaviour document.getElementsByClassName('sth')[0]?.closest('ul');
        mejutoco 4y ago
        Thanks, this is now standard it seems. TIL
        zimpenfish 4y ago
        That's not exactly the same, I don't think, because jQuery will give you all the `ul` that are closest to `.sth`, not just the first. You'd have to write a loop over the list returned from `document.getElementsByClassName('sth')` to get the same behaviour (because it doesn't look like the standardised `closest` works on lists.)
        CraigJPerry 4y ago
    - deleted 4y ago
      [deleted]
    - SemanticStrengh 4y ago
      It's not because you know how to do a hello world that you know how to program.
    - DeathArrow 4y ago
      And you would replace $.getJSON by how many lines?
      - nobleach 4y ago
        are we doing CORS? Adding headers? If it is just a one-off fetch, I'd probably long-hand it. If I intended to be fetching from many endpoints, I'd probably write a tiny little abstraction. I'm not exactly keen on loading a 30kb lib (gzipped) so that I can write (maybe) fewer lines for data fetching. Especially considering jQuery's async requests don't conform to the fetch standard. (They reject on 404s)
- cmer 4y ago
  I think it's a bit of both. jQuery served the purpose of making web development more sane back in the day by handling all browser quirks. Part of that was the nice syntax. I personally have tried to drop jQuery, but truthfully, its syntax is just much easier to use. Nowadays, I use Cash https://github.com/fabiospampinato/cash https://github.com/fabiospampinato/cash to give me the nice syntax without the bloat. It strikes the perfect balance for me.
  - acomjean 4y ago
    I did a javascript project targeting web/blackberry and early ios. We used jQuery to smooth out the kinks (or that's what our lead told us). It worked as expected. Went from disliking it to really liking the syntax. Its pretty clear and easy to use, which is why I still use it. We don't use it extensively becaue we're still on the "submit form, get page back with javascript graph and data tables table, development model. We probably should transition to a framework, but they evolve so quickly ...
  - masklinn 4y ago
    > I personally have tried to drop jQuery, but truthfully, its syntax is just much easier to use. It's not just the syntax, it's also the expression-heavy and chained API which makes it much more flexible. As well as the set-oriented approach, which can lead to performance issues if you're not careful but is generally extremely enjoyable. The DOM is an extremely procedural, plodding API, you need to name everything because you always need to set attributes and call non-chainable side-effecting APIs, not to mention the fecking NodeList which has to be converted to an array to do basically anything useful (in part because Javascript never really embraced iterators, and instead uses arrays for everything still). I guess you could mitigate that with an "API adapter", but...
  - mmis1000 4y ago
    Although writing jQuery is still shorter (And likely will forever be). Editor (like vscode) nowadays is much more smarter then the era. A lot of API with long names is no longer a issue to type. You just mark the variable as a element. After that, autocomplete handles the rest for you. Shorten the gap with experience of using jQuery. If developer tools is still as dumb as that era. I would think the transition is impossible. And there are also more frameworks to enhance experience of style modification or templating. Back to then, there are only some dumb template that do initial rendering. But framework these days also handles update for you. So you don't really need to modify it directly by yourself unless in some edge case.
- icedchai 4y ago
  Yes, the DOM API is painful to work with.
  - moffkalast 4y ago
    Time to drag out this old classic: https://pics.me.me/what-does-l-use-jquery-jquery-mean-tmeans-hes-afraid-44644676.png https://pics.me.me/what-does-l-use-jquery-jquery-mean-tmeans...
    - icedchai 4y ago
      Hah. My first "web apps" were CGI scripts back in 1995. I know enough about the DOM to know that it sucks: document.getElementById is too verbose. I can either define my own function as a shortcut, or use a standard approach for the same. jQuery is that standard approach.
- deleted 4y ago
  [deleted]
- ldiracdelta 4y ago
  I think that the improved vanilla js is now "satisficing" for more people. Their threshold of ergonomic usability has been achieved and they stop looking: https://en.wikipedia.org/wiki/Satisficing https://en.wikipedia.org/wiki/Satisficing
  - SemanticStrengh 4y ago
    or the curse of being good enough. Good concept! :)
legitster 4y ago
> jQuery was making up for browser API shortcomings While this is true, I can still code circles around frontend developers using vanilla JS. The decline of jQuery is mostly due to the rise of webapp frameworks like React and Vue. But if you are tasked with adding like, a button to a static webpage, jQuery is still the king.
- ulisesrmzroche 4y ago
  I call bullshit on all accounts. If someone actually tasked you with adding a button to a webpage...
- wnevets 4y ago
  one of the nice features of AngularJS when it came out was the inclusion of the jquery lite api for interacting with the dom.
- martin_a 4y ago
  I never really knew jQuery besides the five things that I googled, so once I had to do more "dynamic" frontend things I just looked into Vanilla JS and it kind of works for me. Not sure if I had WTF-moments besides the normal "this seems to be how things work" stuff, so I think it's easy enough?!? Only thing I always have to look up is how to make sure my script is executed once everything is done and not before and "ready()" is obviously easier than adding an event listener to "DOMContentLoaded". Yeah, had to look it up for the comment.
  - legitster 4y ago
    Simplifying interaction with the DOM is obviously a huge feature of jQuery. But also the functions are just very nicely laid out with the assumption you are doing web stuff. $(thing).doThis() is just so perfectly terse and understandable for what it's doing. Not just writing, I find jQuery to be very, very easy to understand and read.
    - martin_a 4y ago
      Yeah, you're right. Maybe I should give jQuery another look. :-)
hinkley 4y ago
When people have said this to me in the past I would trot out a list of features that were still useful, but there are one or two where I think the defaults are backward. There was a long time between when "jQuery is dead" and parent selectors of any kind existed, and list comprehension is still a huge miss. I still wonder occasionally if there's a place for a library that works like a strict subset of jQuery, but with different error/empty set handling defaults. Especially with list comprehensions. I found that 9 times out of 10 if I run a selector I'm expecting results, and jQuery will silently eat that error, requiring a bunch of inline error handling in the 'interesting' paths in your code. I'd be much happier with an optional parameter for silent failure or even writing the occasional try/catch.

by jjice 4y ago

dgb23 4y ago

I agree. Also reminds me of CSS resets, the goal of modern-normalize is to make itself obsolete.

SemanticStrengh 4y ago

I really don't get this discourse, jQuery API is much more ergonomic, concise and clearer than the DOM api. Sure you can do it but that doesn't mean you should

threatofrain 4y ago
Ad hoc manipulation of the DOM contradicts the philosophy of a lot of frameworks, as that is state which is unaccounted for.
pastor_bob 4y ago
Just replace that one liner with a 15 liner.
- LNSY 4y ago
  document.querySelector('html') And for React: https://javascript.info/custom-elements https://javascript.info/custom-elements
  - mejutoco 4y ago
    Other functions are much more difficult to replace $('.sth').closest('ul') To me jQuery is like Regex or Linq. I think it had a really good api.
    - frosted-flakes 4y ago
      You can also do this with DOM APIs, no? https://developer.mozilla.org/en-US/docs/Web/API/Element/closest https://developer.mozilla.org/en-US/docs/Web/API/Element/clo...
      - augusto-moura 4y ago
        Is not the same thing as it is a Element method, not NodeList one, so you will would need to map it instead. Because NodeList doesn't have the .map method you would also need to transform it to a Array first. So the actually drop-in replacement of `$(foo).closest(bar)` would be something like: Array.from(document.querySelector(foo)).map(el => el.closest(bar))
      - mejutoco 4y ago
        This did not exist the last time I looked. TIL. Thank you!
    - CraigJPerry 4y ago
      Is it harder or just a bit longer-winded? E.g. i'm thinking this is the same behaviour document.getElementsByClassName('sth')[0]?.closest('ul');
      - mejutoco 4y ago
        Thanks, this is now standard it seems. TIL
      - zimpenfish 4y ago
        That's not exactly the same, I don't think, because jQuery will give you all the `ul` that are closest to `.sth`, not just the first. You'd have to write a loop over the list returned from `document.getElementsByClassName('sth')` to get the same behaviour (because it doesn't look like the standardised `closest` works on lists.)
        CraigJPerry 4y ago
  - deleted 4y ago
    [deleted]
  - SemanticStrengh 4y ago
    It's not because you know how to do a hello world that you know how to program.
  - DeathArrow 4y ago
    And you would replace $.getJSON by how many lines?
    - nobleach 4y ago
      are we doing CORS? Adding headers? If it is just a one-off fetch, I'd probably long-hand it. If I intended to be fetching from many endpoints, I'd probably write a tiny little abstraction. I'm not exactly keen on loading a 30kb lib (gzipped) so that I can write (maybe) fewer lines for data fetching. Especially considering jQuery's async requests don't conform to the fetch standard. (They reject on 404s)
cmer 4y ago
I think it's a bit of both. jQuery served the purpose of making web development more sane back in the day by handling all browser quirks. Part of that was the nice syntax. I personally have tried to drop jQuery, but truthfully, its syntax is just much easier to use. Nowadays, I use Cash https://github.com/fabiospampinato/cash https://github.com/fabiospampinato/cash to give me the nice syntax without the bloat. It strikes the perfect balance for me.
- acomjean 4y ago
  I did a javascript project targeting web/blackberry and early ios. We used jQuery to smooth out the kinks (or that's what our lead told us). It worked as expected. Went from disliking it to really liking the syntax. Its pretty clear and easy to use, which is why I still use it. We don't use it extensively becaue we're still on the "submit form, get page back with javascript graph and data tables table, development model. We probably should transition to a framework, but they evolve so quickly ...
- masklinn 4y ago
  > I personally have tried to drop jQuery, but truthfully, its syntax is just much easier to use. It's not just the syntax, it's also the expression-heavy and chained API which makes it much more flexible. As well as the set-oriented approach, which can lead to performance issues if you're not careful but is generally extremely enjoyable. The DOM is an extremely procedural, plodding API, you need to name everything because you always need to set attributes and call non-chainable side-effecting APIs, not to mention the fecking NodeList which has to be converted to an array to do basically anything useful (in part because Javascript never really embraced iterators, and instead uses arrays for everything still). I guess you could mitigate that with an "API adapter", but...
- mmis1000 4y ago
  Although writing jQuery is still shorter (And likely will forever be). Editor (like vscode) nowadays is much more smarter then the era. A lot of API with long names is no longer a issue to type. You just mark the variable as a element. After that, autocomplete handles the rest for you. Shorten the gap with experience of using jQuery. If developer tools is still as dumb as that era. I would think the transition is impossible. And there are also more frameworks to enhance experience of style modification or templating. Back to then, there are only some dumb template that do initial rendering. But framework these days also handles update for you. So you don't really need to modify it directly by yourself unless in some edge case.
icedchai 4y ago
Yes, the DOM API is painful to work with.
- moffkalast 4y ago
  Time to drag out this old classic: https://pics.me.me/what-does-l-use-jquery-jquery-mean-tmeans-hes-afraid-44644676.png https://pics.me.me/what-does-l-use-jquery-jquery-mean-tmeans...
  - icedchai 4y ago
    Hah. My first "web apps" were CGI scripts back in 1995. I know enough about the DOM to know that it sucks: document.getElementById is too verbose. I can either define my own function as a shortcut, or use a standard approach for the same. jQuery is that standard approach.
deleted 4y ago
[deleted]
ldiracdelta 4y ago
I think that the improved vanilla js is now "satisficing" for more people. Their threshold of ergonomic usability has been achieved and they stop looking: https://en.wikipedia.org/wiki/Satisficing https://en.wikipedia.org/wiki/Satisficing
- SemanticStrengh 4y ago
  or the curse of being good enough. Good concept! :)

legitster 4y ago

> jQuery was making up for browser API shortcomings While this is true, I can still code circles around frontend developers using vanilla JS. The decline of jQuery is mostly due to the rise of webapp frameworks like React and Vue. But if you are tasked with adding like, a button to a static webpage, jQuery is still the king.

ulisesrmzroche 4y ago
I call bullshit on all accounts. If someone actually tasked you with adding a button to a webpage...
wnevets 4y ago
one of the nice features of AngularJS when it came out was the inclusion of the jquery lite api for interacting with the dom.
martin_a 4y ago
I never really knew jQuery besides the five things that I googled, so once I had to do more "dynamic" frontend things I just looked into Vanilla JS and it kind of works for me. Not sure if I had WTF-moments besides the normal "this seems to be how things work" stuff, so I think it's easy enough?!? Only thing I always have to look up is how to make sure my script is executed once everything is done and not before and "ready()" is obviously easier than adding an event listener to "DOMContentLoaded". Yeah, had to look it up for the comment.
- legitster 4y ago
  Simplifying interaction with the DOM is obviously a huge feature of jQuery. But also the functions are just very nicely laid out with the assumption you are doing web stuff. $(thing).doThis() is just so perfectly terse and understandable for what it's doing. Not just writing, I find jQuery to be very, very easy to understand and read.
  - martin_a 4y ago
    Yeah, you're right. Maybe I should give jQuery another look. :-)

hinkley 4y ago

When people have said this to me in the past I would trot out a list of features that were still useful, but there are one or two where I think the defaults are backward. There was a long time between when "jQuery is dead" and parent selectors of any kind existed, and list comprehension is still a huge miss. I still wonder occasionally if there's a place for a library that works like a strict subset of jQuery, but with different error/empty set handling defaults. Especially with list comprehensions. I found that 9 times out of 10 if I run a selector I'm expecting results, and jQuery will silently eat that error, requiring a bunch of inline error handling in the 'interesting' paths in your code. I'd be much happier with an optional parameter for silent failure or even writing the occasional try/catch.