8 ms·

I think it's not really needed in today's browser landscape unless you're working on a team that uses it. I prefer fetch, document.querySelectorAll, and animat

I think it's not really needed in today's browser landscape unless you're working on a team that uses it. I prefer fetch, document.querySelectorAll, and animate.css for 90% of what you would need with jQuery.

peteforde 8y ago
While I respect that this comment is an expression of your lived experience (after all, I used the word believe so this is fair game) I am compelled to point out that when you say "of what you would need with jQuery", what you really mean is "what I would need with jQuery". You know how there's ~3 kinds of Excel users? You have your formatted rows and columns types, people like me that can use SUM(), call APIs and know what pivot tables are... and then there are those ninjas that can implement ray-traced dungeon renderers in a cell. https://www.youtube.com/watch?v=iCeOEQVUWZ0 https://www.youtube.com/watch?v=iCeOEQVUWZ0 I'm not exactly claiming Carmack-level jQuery proficiency, but comments like yours make me wonder (optimistically) whether you've forgotten all of the amazingly useful things that jQuery can do. Ajax, selectors and CSS transitions are the Nickelback of creative possibility. As a final note, I am excited that things which once required jQuery are now being solved by the browser and the evolving EcmaScript standard. Ideally, jQuery continues to get smaller and smaller. However, it's intellectually dishonest to claim that all of the non-jQuery techniques are as ergonomic to implement as jQuery idioms. Proof: http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/ I do really like fetch and async/await in general, and working in React has taught me lots of cool tricks to bring back to my real projects. I think everyone should try to build something real with React, just to understand how lucky they are to have the option not to use it.
- revvx 8y ago
  > I'm not exactly claiming Carmack-level jQuery proficiency, but comments like yours make me wonder (optimistically) whether you've forgotten all of the amazingly useful things that jQuery can do. Ajax, selectors and CSS transitions are the Nickelback of creative possibility. It's been several years since I last used jQuery, but what are those other useful things that are hard using Vanilla.js? (Legitimate question, not being sarcastic here)
  - holoduke 8y ago
    Dom regex selectors. jQuery has extremely powerful and smart ways of retrieving elements that way.
    - rajangdavis 8y ago
      I feel as though that if you need regex selectors, there is something wrong with the structure of your HTML. Can you tell me which use case you would need to do this? I don't think there is anything wrong with this functionality, but it seems like if you needed it, that your HTML is needlessly complex.
      - DCoder 8y ago
        I'm not the parent poster, and I'm not sure if these are the regex selectors they had in mind, but nonetheless. An example use case: the person writing the HTML ≠ the person writing the selectors. Browser extensions like Stylus, for example. If the HTML author did not bother to add a specific class you need, you have to resort to ugly methods. In fact, this is a scenario I deal with regularly. I have a Chrome extension for video download sites that scans the current page for metadata (title, performers, release date, etc.) and decorates the download links with `download="…"` attributes, so that I can download a file with a properly formatted filename. I manually adapt this extension to every site I need, and quite often I need things like `a[href^=/model/]` † to distinguish links to performers from other links to get their text content. It's clearly not a situation the site authors worry about, and that's fine as long as I have a way to do this myself. † This particular selector can be done without jQuery if you don't care about backcompat. In browser extensions, you usually don't. But it's still an answer to your question about when such selectors are needed. --- Since I'm talking about this, that same browser extension can demonstrate some other complications brought on by React and CSS-in-JS: 1. CSS-in-JS turns class names into unreliable gobbledygook, so extracting metadata means more regex selectors and abominable DOM hierarchy selectors (`section>div>div:first-child>div` because nobody bothers with semantic <h2> or even .title anymore). 2. React makes DOM elements vanish and reappear instead of just hiding them, so that `download="…"` attribute I want to add has to go through a MutationObserver instead of just running once on page load.
- rajangdavis 8y ago
  It might be the case that how I use javascript is Nickelback-level coding; however, it pays the bills and to be frank, I don't miss using jQuery. I don't need my day job to validate my creativity. I don't use React/Vue/Flavor-of-the-month UI library for my day job; however I don't use jQuery either. I am not trying to shit on what can be accomplished with it; however, I debug a lot of code that adds it in where ES6/vanilla javascript does the same thing. I guess I prefer verbose javascript over using jQuery... not trying to knock on it, but it might be worth looking at other tools for the long term. Edit: To be clear, I am not advocating to rip out jQuery fron existing apps. In a lot of cases, jQuery and jQuery plugins are helpful, but most of the code that I am paid to debug ends up being rewritten in vanilla js because I feel comfortable using that. I stopped using jQuery a while back because I opted to use a UI library a while back and worked hard to avoid jQuery ever since even though I don't use UI libraries at my current job. Use whatever tool floats your boat and doesn't piss off the rest of your team. It's possible to ship spaghetti code in any flavor you want. I happen to (currently) work on things where the level of complexity of the UI is simple enough to use vanilla JS and not need a UI framework.
  - marvindanig 8y ago
    And what do you do about accessibility? Working with jQuery makes sure you have a baseline default that's always accessible. Also, jQuery is not backed by a terrible organization with a questionable record, even evil intent. I love jQuery and will switch for vanilla JS only when it's okay to do so, like when support on old browsers isn't that much of a priority.
    - rajangdavis 8y ago
      I use vanilla js for WCAG compliance; however, I only need to focus on IE11+ for most work because TLS 1.2 support is mandatory for the sites I support.
  - peteforde 8y ago
    I don't understand why this comment was down-voted; this is a completely reasonable perspective. Plus, it reminds me that I'm lucky in the projects I typically get to work on, that they still allow for creative coding in many moments. If coding is your day job and you work on corporate applications, it's likely that you're on a team big enough to start discussing how things like React might be necessary and valuable. If you're building a linear CRUD application, you probably still don't need Reactive frameworks, but you're in the right ballpark to be talking about it. Otherwise, history will not be kind.
- EB66 8y ago
  youmightnotneedjquery.com is often held up as an example of why jQuery is obsolete, but if you look at the examples a bit more closely, you'll notice problems. I spent all of five minutes glancing through the example list and noticed their `replaceWith` doesn't provide the functionality that jQuery offers -- it doesn't take into account event handlers bound to DOM elements. Also, their `extend` does a shallow merge, not a deep merge. Furthermore, the YMNNJ examples are often far more verbose and less expressive than the jQuery examples. I don't particularly understand the rush to rip jQuery out of everything. It seems like a lot of people are doing it just because it's the trending thing to do. There are some things that jQuery does very well -- even in today's world where modern web dev is dominated by SPA components. I'm the maintainer of https://github.com/elliotnb/observable-slim https://github.com/elliotnb/observable-slim and https://github.com/elliotnb/nimbly https://github.com/elliotnb/nimbly -- the latter of which is an SPA component framework whose core requires jQuery. It uses jQuery to update DOM nodes with `replaceWith`, merge deeply nested objects with `extend`, among other things. Nimbly components are not required to use jQuery -- only the framework core uses it. Aside from the eliminating the extra 69KB footprint from adding jQuery slim min, I don't see any reason to rush to rip jQuery out of the Nimbly core. On the contrary, using jQuery helped us get the framework built faster and helped us keep the code expressive and easy-to-follow.
  - masklinn 8y ago
    > youmightnotneedjquery.com is often held up as an example of why jQuery is obsolete, but if you look at the examples a bit more closely, you'll notice problems. Surely that's their entire point? They provide the link as evidence that > it's intellectually dishonest to claim that all of the non-jQuery techniques are as ergonomic to implement as jQuery idioms Not as evidence that you don't need jquery.
    - peteforde 8y ago
      You could be right... but you're definitely the first person I've seen suggest this. It would be a Sixth Sense twist, given the domain name. youprobablystillwantjquery.com is still available at the time of this writing.
- ricardobeat 8y ago
  > http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/ The examples in the site already look quite outdated. We now have `fetch()`, `.attachEvent` is all but dead, plus all the ES6 features like arrow functions, destructuring, spread... and reactive UI means you'll rarely, if ever, need to call DOM tree modifying methods yourself. The best part, "Reactive UI" being a paradigm, you have many other options besides React+JSX, for example https://github.com/jorgebucaran/hyperapp https://github.com/jorgebucaran/hyperapp. At a fraction of the size of jQuery, which one is the 'monster'?
  - peteforde 8y ago
    I can't speak for the others, but when I talk about Reactive monsters, I am talking about needless complexity - both in setup and in usage. I believe that the relative size of one library vs another (even outside of the reality of caching CDNs) is an unhelpful distraction from the bigger discussion around who should consider using which tools for which jobs, when. The applications I'm working on are typically for people with usable broadband connections. If you build your site/app correctly, the pictures that are embedded in your content are often bigger than any of the libraries you could choose. However, it's the general responsiveness of your experience that people will judge your speed or "nativeness" by. I do agree that the examples on the site are somewhat outdated, but the fact remains that there are a lot of nice things to say about that dang left column, with its predictable, intuitive and impressively terse invocations.
    - ricardobeat 8y ago
      I worked for ~8 years using jQuery. It was an immense step forward in the early years, but these days I find the complexity of imperative code and juggling state from multiple sources a lot worse than the ‘complexity’ of a 100-line diff & patch algorithm that lets me simply redraw the whole world from state. And in the event I need to manipulate the DOM, the native APIs are now good enough, a couple extra lines are worth not having an extra dependency - jQuery’s (and zepto and so on) utility is diminished.
- porker 8y ago
  > Ajax, selectors and CSS transitions are the Nickelback of creative possibility. And the jQuery Ajax methods are super-handy. POST with the fetch API is long-winded; while the jQuery promise-handling sucks, it was enough to make me use $.post() in the current project.
  - bmn__ 8y ago
    > while the jQuery promise-handling sucks You don't need to use that API. Deferred is compatible with Promise, you can just simply `await $.post()` etc. See last section of http://api.jquery.com/jQuery.Deferred/ http://api.jquery.com/jQuery.Deferred/
    - porker 8y ago
      Awesome thank you, I didn't know this!
mariusmg 8y ago
That's true only if you target the latest version of each browser. Otherwise backward compatibility will quickly eat you alive...
- rajangdavis 8y ago
  I've gotten pretty far with Mithril and polyfills (mainly for JSON support) targetting IE7. If you're worried about backwards compatibility, then jQuery is the right tool; however, if less than 2% of your users are using an unsupported version of Internet Explorer, I would spend more time flashing a message instructing these users to upgrade.
  - peteforde 8y ago
    We definitely agree on this topic. I'm only going to live for a finite amount of time, and I refuse to spend another microsecond supporting legacy IE.

peteforde 8y ago

While I respect that this comment is an expression of your lived experience (after all, I used the word believe so this is fair game) I am compelled to point out that when you say "of what you would need with jQuery", what you really mean is "what I would need with jQuery". You know how there's ~3 kinds of Excel users? You have your formatted rows and columns types, people like me that can use SUM(), call APIs and know what pivot tables are... and then there are those ninjas that can implement ray-traced dungeon renderers in a cell. https://www.youtube.com/watch?v=iCeOEQVUWZ0 https://www.youtube.com/watch?v=iCeOEQVUWZ0 I'm not exactly claiming Carmack-level jQuery proficiency, but comments like yours make me wonder (optimistically) whether you've forgotten all of the amazingly useful things that jQuery can do. Ajax, selectors and CSS transitions are the Nickelback of creative possibility. As a final note, I am excited that things which once required jQuery are now being solved by the browser and the evolving EcmaScript standard. Ideally, jQuery continues to get smaller and smaller. However, it's intellectually dishonest to claim that all of the non-jQuery techniques are as ergonomic to implement as jQuery idioms. Proof: http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/ I do really like fetch and async/await in general, and working in React has taught me lots of cool tricks to bring back to my real projects. I think everyone should try to build something real with React, just to understand how lucky they are to have the option not to use it.

revvx 8y ago
> I'm not exactly claiming Carmack-level jQuery proficiency, but comments like yours make me wonder (optimistically) whether you've forgotten all of the amazingly useful things that jQuery can do. Ajax, selectors and CSS transitions are the Nickelback of creative possibility. It's been several years since I last used jQuery, but what are those other useful things that are hard using Vanilla.js? (Legitimate question, not being sarcastic here)
- holoduke 8y ago
  Dom regex selectors. jQuery has extremely powerful and smart ways of retrieving elements that way.
  - rajangdavis 8y ago
    I feel as though that if you need regex selectors, there is something wrong with the structure of your HTML. Can you tell me which use case you would need to do this? I don't think there is anything wrong with this functionality, but it seems like if you needed it, that your HTML is needlessly complex.
    - DCoder 8y ago
      I'm not the parent poster, and I'm not sure if these are the regex selectors they had in mind, but nonetheless. An example use case: the person writing the HTML ≠ the person writing the selectors. Browser extensions like Stylus, for example. If the HTML author did not bother to add a specific class you need, you have to resort to ugly methods. In fact, this is a scenario I deal with regularly. I have a Chrome extension for video download sites that scans the current page for metadata (title, performers, release date, etc.) and decorates the download links with `download="…"` attributes, so that I can download a file with a properly formatted filename. I manually adapt this extension to every site I need, and quite often I need things like `a[href^=/model/]` † to distinguish links to performers from other links to get their text content. It's clearly not a situation the site authors worry about, and that's fine as long as I have a way to do this myself. † This particular selector can be done without jQuery if you don't care about backcompat. In browser extensions, you usually don't. But it's still an answer to your question about when such selectors are needed. --- Since I'm talking about this, that same browser extension can demonstrate some other complications brought on by React and CSS-in-JS: 1. CSS-in-JS turns class names into unreliable gobbledygook, so extracting metadata means more regex selectors and abominable DOM hierarchy selectors (`section>div>div:first-child>div` because nobody bothers with semantic <h2> or even .title anymore). 2. React makes DOM elements vanish and reappear instead of just hiding them, so that `download="…"` attribute I want to add has to go through a MutationObserver instead of just running once on page load.
rajangdavis 8y ago
It might be the case that how I use javascript is Nickelback-level coding; however, it pays the bills and to be frank, I don't miss using jQuery. I don't need my day job to validate my creativity. I don't use React/Vue/Flavor-of-the-month UI library for my day job; however I don't use jQuery either. I am not trying to shit on what can be accomplished with it; however, I debug a lot of code that adds it in where ES6/vanilla javascript does the same thing. I guess I prefer verbose javascript over using jQuery... not trying to knock on it, but it might be worth looking at other tools for the long term. Edit: To be clear, I am not advocating to rip out jQuery fron existing apps. In a lot of cases, jQuery and jQuery plugins are helpful, but most of the code that I am paid to debug ends up being rewritten in vanilla js because I feel comfortable using that. I stopped using jQuery a while back because I opted to use a UI library a while back and worked hard to avoid jQuery ever since even though I don't use UI libraries at my current job. Use whatever tool floats your boat and doesn't piss off the rest of your team. It's possible to ship spaghetti code in any flavor you want. I happen to (currently) work on things where the level of complexity of the UI is simple enough to use vanilla JS and not need a UI framework.
- marvindanig 8y ago
  And what do you do about accessibility? Working with jQuery makes sure you have a baseline default that's always accessible. Also, jQuery is not backed by a terrible organization with a questionable record, even evil intent. I love jQuery and will switch for vanilla JS only when it's okay to do so, like when support on old browsers isn't that much of a priority.
  - rajangdavis 8y ago
    I use vanilla js for WCAG compliance; however, I only need to focus on IE11+ for most work because TLS 1.2 support is mandatory for the sites I support.
- peteforde 8y ago
  I don't understand why this comment was down-voted; this is a completely reasonable perspective. Plus, it reminds me that I'm lucky in the projects I typically get to work on, that they still allow for creative coding in many moments. If coding is your day job and you work on corporate applications, it's likely that you're on a team big enough to start discussing how things like React might be necessary and valuable. If you're building a linear CRUD application, you probably still don't need Reactive frameworks, but you're in the right ballpark to be talking about it. Otherwise, history will not be kind.
EB66 8y ago
youmightnotneedjquery.com is often held up as an example of why jQuery is obsolete, but if you look at the examples a bit more closely, you'll notice problems. I spent all of five minutes glancing through the example list and noticed their `replaceWith` doesn't provide the functionality that jQuery offers -- it doesn't take into account event handlers bound to DOM elements. Also, their `extend` does a shallow merge, not a deep merge. Furthermore, the YMNNJ examples are often far more verbose and less expressive than the jQuery examples. I don't particularly understand the rush to rip jQuery out of everything. It seems like a lot of people are doing it just because it's the trending thing to do. There are some things that jQuery does very well -- even in today's world where modern web dev is dominated by SPA components. I'm the maintainer of https://github.com/elliotnb/observable-slim https://github.com/elliotnb/observable-slim and https://github.com/elliotnb/nimbly https://github.com/elliotnb/nimbly -- the latter of which is an SPA component framework whose core requires jQuery. It uses jQuery to update DOM nodes with `replaceWith`, merge deeply nested objects with `extend`, among other things. Nimbly components are not required to use jQuery -- only the framework core uses it. Aside from the eliminating the extra 69KB footprint from adding jQuery slim min, I don't see any reason to rush to rip jQuery out of the Nimbly core. On the contrary, using jQuery helped us get the framework built faster and helped us keep the code expressive and easy-to-follow.
- masklinn 8y ago
  > youmightnotneedjquery.com is often held up as an example of why jQuery is obsolete, but if you look at the examples a bit more closely, you'll notice problems. Surely that's their entire point? They provide the link as evidence that > it's intellectually dishonest to claim that all of the non-jQuery techniques are as ergonomic to implement as jQuery idioms Not as evidence that you don't need jquery.
  - peteforde 8y ago
    You could be right... but you're definitely the first person I've seen suggest this. It would be a Sixth Sense twist, given the domain name. youprobablystillwantjquery.com is still available at the time of this writing.
ricardobeat 8y ago
> http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/ The examples in the site already look quite outdated. We now have `fetch()`, `.attachEvent` is all but dead, plus all the ES6 features like arrow functions, destructuring, spread... and reactive UI means you'll rarely, if ever, need to call DOM tree modifying methods yourself. The best part, "Reactive UI" being a paradigm, you have many other options besides React+JSX, for example https://github.com/jorgebucaran/hyperapp https://github.com/jorgebucaran/hyperapp. At a fraction of the size of jQuery, which one is the 'monster'?
- peteforde 8y ago
  I can't speak for the others, but when I talk about Reactive monsters, I am talking about needless complexity - both in setup and in usage. I believe that the relative size of one library vs another (even outside of the reality of caching CDNs) is an unhelpful distraction from the bigger discussion around who should consider using which tools for which jobs, when. The applications I'm working on are typically for people with usable broadband connections. If you build your site/app correctly, the pictures that are embedded in your content are often bigger than any of the libraries you could choose. However, it's the general responsiveness of your experience that people will judge your speed or "nativeness" by. I do agree that the examples on the site are somewhat outdated, but the fact remains that there are a lot of nice things to say about that dang left column, with its predictable, intuitive and impressively terse invocations.
  - ricardobeat 8y ago
    I worked for ~8 years using jQuery. It was an immense step forward in the early years, but these days I find the complexity of imperative code and juggling state from multiple sources a lot worse than the ‘complexity’ of a 100-line diff & patch algorithm that lets me simply redraw the whole world from state. And in the event I need to manipulate the DOM, the native APIs are now good enough, a couple extra lines are worth not having an extra dependency - jQuery’s (and zepto and so on) utility is diminished.
porker 8y ago
> Ajax, selectors and CSS transitions are the Nickelback of creative possibility. And the jQuery Ajax methods are super-handy. POST with the fetch API is long-winded; while the jQuery promise-handling sucks, it was enough to make me use $.post() in the current project.
- bmn__ 8y ago
  > while the jQuery promise-handling sucks You don't need to use that API. Deferred is compatible with Promise, you can just simply `await $.post()` etc. See last section of http://api.jquery.com/jQuery.Deferred/ http://api.jquery.com/jQuery.Deferred/
  - porker 8y ago
    Awesome thank you, I didn't know this!

mariusmg 8y ago

That's true only if you target the latest version of each browser. Otherwise backward compatibility will quickly eat you alive...

rajangdavis 8y ago
I've gotten pretty far with Mithril and polyfills (mainly for JSON support) targetting IE7. If you're worried about backwards compatibility, then jQuery is the right tool; however, if less than 2% of your users are using an unsupported version of Internet Explorer, I would spend more time flashing a message instructing these users to upgrade.
- peteforde 8y ago
  We definitely agree on this topic. I'm only going to live for a finite amount of time, and I refuse to spend another microsecond supporting legacy IE.