4 ms·

Aren't people afraid of being kicked and beaten with sticks in 2019 if they build things with jQuery.

have_faith 7y ago
It's a shame jQuery gets demonised so much, it's still a great tool to use even in 2019. Don't use it for the wrong job (web apps) and there's nothing wrong with it. It's actually strange you can meet people who learned something like React/Angular as an intro JavaScript and don't know how to do simple things outside of a framework without a tutorial.
- FreeFull 7y ago
  Modern Javascript standards have incorporated a lot of things that have started their life in jQuery. What advantages does jQuery still have?
  - rofo1 7y ago
    Sure, when you need to update 1 single thing once, you can use vanilla js. But when you need to do more than that, you'll realize jQuery is still useful (assuming you don't use a framework or whatever). Either you will use something like jQuery or you'll reinvent by writing the methods yourself. IMO it's still relevant, despite the hype of other frameworks.
    - staticvar 7y ago
      > But when you need to do more than that, you'll realize jQuery is still useful Such as?
      - purerandomness 7y ago
        See here: https://medium.com/@mattburgess/in-defence-of-jquery-4a8b20f4696b https://medium.com/@mattburgess/in-defence-of-jquery-4a8b20f... In general, jQuery is an amazing wrapper around native JS with a saner API and countless hours of different browser quirk workarounds to make sure that what you try to do works in all modern browsers and IE.
    - onion2k 7y ago
      There's really nothing you need jQuery for any more except supporting old jQuery components. You can do things like Array.from(document.querySelectorAll('.foo')).map((fooEl)=>{ fooEl.classList.toggle('bar'); }) in a browser (with no Babel-style transpile step) these days. In case you want to play with that - https://codepen.io/onion2k/pen/NQrEKq https://codepen.io/onion2k/pen/NQrEKq
      - yrwwywtywsrty 7y ago
        Although I usually agree with the 'jQuery is overused' side of the crowd, I think your example is one of the times when I see that jQuery wins in ease and readability. The jQuery equivalent for this is $('.foo').addClass('bar');
        chrismorgan 7y ago
        I really dislike the way jQuery makes no distinction between mutations on one or many elements. I view the native APIs’ differentiation of the two, requring you to be explicit (`document.querySelector('.foo').classList.add('bar')` versus `document.querySelectorAll('.foo').forEach(foo => foo.classList.add('bar'))`) to be a feature.
        onion2k 7y ago
        My version doesn't need a 30Kb library though.
      - chrismorgan 7y ago
        Some notes: • Array.from is comparatively recent to the web platform, and cuts out IE support. • Learn when to use Array.prototype.forEach, and when to use Array.prototype.map: use forEach when you aren’t deliberately constructing a new array but are just wanting to call a function on each value, and map when you are applying a function to each value and care about the result. Otherwise you’re creating a new array unnecessarily. • You can (and should) avoid Array.from when you just want to call an array method on an array-like object (e.g. NodeList, HTMLCollection, Arguments): instead, call the method directly on the instance; it’s OK, all the Array.prototype methods are deliberately designed to work on array-like objects, not just arrays. That is, instead of `Array.from(x).forEach(y)`, use `Array.prototype.forEach.call(x, y)`. Otherwise you’re creating a new array unnecessarily. • A slight word of caution about classList: IE and very old browsers don’t implement it on SVG elements. Just take that into account if you support IE at all. So then, you might end up with this: Array.prototype.forEach.call(document.querySelectorAll('.foo'), (fooEl) => { fooEl.classList.toggle('bar'); }); Or if you hate the `Array.prototype.` and `.call` bits, const forEach = Function.prototype.call.bind(Array.prototype.forEach); forEach(document.querySelectorAll('.foo'), (fooEl) => { fooEl.classList.toggle('bar'); }); And if you’re happy to drop a little more older browser support including IE, you can just use NodeList.prototype.forEach, which incidentally is normally the same function object as Array.prototype.forEach: document.querySelectorAll('.foo').forEach((fooEl) => { fooEl.classList.toggle('bar'); });
  - have_faith 7y ago
    They've incorporated everything other than the convenience and succinctness of jQuery. And that's fine, they have different goals to jQuery, standards should be more explicit in what functions do and how they behave etc. Maybe it's a good thing I can't do $('something').eq(0).addClass('foo') in ES without first checking the return type of document.querySelector before attempting to add a class to it, but it is convenient. Looking at stuff like http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/ it's easy to see why there are lots of cases where jQuery just isn't needed anymore. But 10% of them still look very verbose without jQuery and when I'm working on a simple website the convenience of jQuery is worth it to me so I continue to use it where it helps.
  - 40four 7y ago
    Browser compatibility. Ajax calls are one example. JQuery ajax works everywhere, while fetch() will never work in IE without polyfils. Not to mention all the other ES6 features IE refuses to support. Not every project wants or needs a webpack/ babel build process.
SimianLogic2 7y ago
I still use it for most websites I build. Ruby + jquery are still great! I’ve inherited a ton of backbone, angular, react projects and it’s always a pain sourcing devs for whatever random thing a project was written in 1-8 years ago. Jquery is just jquery and you can put anyone on it. EXCEPT I reached out to the lambda school contractor program for a work project and was pretty shocked they only do node+react.
- tuesdayrain 7y ago
  > EXCEPT I reached out to the lambda school contractor program for a work project and was pretty shocked they only do node+react. They only teach modern, relevant technologies? How shocking.
  - SimianLogic2 7y ago
    This is a bad take. Save your snark for somewhere else. I didn’t say it was the wrong choice or even a bad choice, just that I was surprised. Ruby and jquery are certainly modern technologies. My surprise was more a factor that maybe I had too high of an impression of LS (and I’m still a fan!). The blogs/tweets I’ve seen from afar made it seem more like a rigorous “be a working software engineer” curriculum. If their candidates are ONLY suited for a node/react stack that seems like a pretty dangerous/inflexible hire. TBF this was for folks who haven’t graduated yet, so maybe they go wider on their final few months. As a person who hires engineers, I don’t want someone who only knows one stack. I want smart people who can solve problems in any stack that gets thrown at them (even if they’re junior and I need to hold their hands a bit).
Raphmedia 7y ago
Unless you are doing things like modifying a Google-style speadsheet of 5000+ columns and rows, you won't see much of a performance loss from using jQuery. It does add a microscopic bit of weight to your page and some milliseconds to your load time, but that's it. It's a ressource that is smaller and faster to load than the content of the page. In my opinion, this argument is meaningless. Modern SPA frameworks are slowing the web way more. Loading your jQuery scripts async will make this transparent for the user. In the edge-cases where jQuery is slower than native JS (because of polyfills, mostly), there's nothing stopping you from using those directly. Unless you are Netflix and micro-optimizing your homepage to the millisecond, there's no hard reason to avoid jQuery. I believe that those slight performance losses are worth the trade for the benefits of using a strong and well tested framework that has browser support and lowers development time. I'd trust non JavaScript experts to use jQuery on my projects, I can't say the same for raw JavaScript. Trend-driven development is a pitfall. Boring technologies are where it's at.

It's a shame jQuery gets demonised so much, it's still a great tool to use even in 2019. Don't use it for the wrong job (web apps) and there's nothing wrong with it. It's actually strange you can meet people who learned something like React/Angular as an intro JavaScript and don't know how to do simple things outside of a framework without a tutorial.

FreeFull 7y ago
Modern Javascript standards have incorporated a lot of things that have started their life in jQuery. What advantages does jQuery still have?
- rofo1 7y ago
  Sure, when you need to update 1 single thing once, you can use vanilla js. But when you need to do more than that, you'll realize jQuery is still useful (assuming you don't use a framework or whatever). Either you will use something like jQuery or you'll reinvent by writing the methods yourself. IMO it's still relevant, despite the hype of other frameworks.
  - staticvar 7y ago
    > But when you need to do more than that, you'll realize jQuery is still useful Such as?
    - purerandomness 7y ago
      See here: https://medium.com/@mattburgess/in-defence-of-jquery-4a8b20f4696b https://medium.com/@mattburgess/in-defence-of-jquery-4a8b20f... In general, jQuery is an amazing wrapper around native JS with a saner API and countless hours of different browser quirk workarounds to make sure that what you try to do works in all modern browsers and IE.
  - onion2k 7y ago
    There's really nothing you need jQuery for any more except supporting old jQuery components. You can do things like Array.from(document.querySelectorAll('.foo')).map((fooEl)=>{ fooEl.classList.toggle('bar'); }) in a browser (with no Babel-style transpile step) these days. In case you want to play with that - https://codepen.io/onion2k/pen/NQrEKq https://codepen.io/onion2k/pen/NQrEKq
    - yrwwywtywsrty 7y ago
      Although I usually agree with the 'jQuery is overused' side of the crowd, I think your example is one of the times when I see that jQuery wins in ease and readability. The jQuery equivalent for this is $('.foo').addClass('bar');
      - chrismorgan 7y ago
        I really dislike the way jQuery makes no distinction between mutations on one or many elements. I view the native APIs’ differentiation of the two, requring you to be explicit (`document.querySelector('.foo').classList.add('bar')` versus `document.querySelectorAll('.foo').forEach(foo => foo.classList.add('bar'))`) to be a feature.
      - onion2k 7y ago
        My version doesn't need a 30Kb library though.
    - chrismorgan 7y ago
      Some notes: • Array.from is comparatively recent to the web platform, and cuts out IE support. • Learn when to use Array.prototype.forEach, and when to use Array.prototype.map: use forEach when you aren’t deliberately constructing a new array but are just wanting to call a function on each value, and map when you are applying a function to each value and care about the result. Otherwise you’re creating a new array unnecessarily. • You can (and should) avoid Array.from when you just want to call an array method on an array-like object (e.g. NodeList, HTMLCollection, Arguments): instead, call the method directly on the instance; it’s OK, all the Array.prototype methods are deliberately designed to work on array-like objects, not just arrays. That is, instead of `Array.from(x).forEach(y)`, use `Array.prototype.forEach.call(x, y)`. Otherwise you’re creating a new array unnecessarily. • A slight word of caution about classList: IE and very old browsers don’t implement it on SVG elements. Just take that into account if you support IE at all. So then, you might end up with this: Array.prototype.forEach.call(document.querySelectorAll('.foo'), (fooEl) => { fooEl.classList.toggle('bar'); }); Or if you hate the `Array.prototype.` and `.call` bits, const forEach = Function.prototype.call.bind(Array.prototype.forEach); forEach(document.querySelectorAll('.foo'), (fooEl) => { fooEl.classList.toggle('bar'); }); And if you’re happy to drop a little more older browser support including IE, you can just use NodeList.prototype.forEach, which incidentally is normally the same function object as Array.prototype.forEach: document.querySelectorAll('.foo').forEach((fooEl) => { fooEl.classList.toggle('bar'); });
- have_faith 7y ago
  They've incorporated everything other than the convenience and succinctness of jQuery. And that's fine, they have different goals to jQuery, standards should be more explicit in what functions do and how they behave etc. Maybe it's a good thing I can't do $('something').eq(0).addClass('foo') in ES without first checking the return type of document.querySelector before attempting to add a class to it, but it is convenient. Looking at stuff like http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/ it's easy to see why there are lots of cases where jQuery just isn't needed anymore. But 10% of them still look very verbose without jQuery and when I'm working on a simple website the convenience of jQuery is worth it to me so I continue to use it where it helps.
- 40four 7y ago
  Browser compatibility. Ajax calls are one example. JQuery ajax works everywhere, while fetch() will never work in IE without polyfils. Not to mention all the other ES6 features IE refuses to support. Not every project wants or needs a webpack/ babel build process.

SimianLogic2 7y ago

I still use it for most websites I build. Ruby + jquery are still great! I’ve inherited a ton of backbone, angular, react projects and it’s always a pain sourcing devs for whatever random thing a project was written in 1-8 years ago. Jquery is just jquery and you can put anyone on it. EXCEPT I reached out to the lambda school contractor program for a work project and was pretty shocked they only do node+react.

tuesdayrain 7y ago
> EXCEPT I reached out to the lambda school contractor program for a work project and was pretty shocked they only do node+react. They only teach modern, relevant technologies? How shocking.
- SimianLogic2 7y ago
  This is a bad take. Save your snark for somewhere else. I didn’t say it was the wrong choice or even a bad choice, just that I was surprised. Ruby and jquery are certainly modern technologies. My surprise was more a factor that maybe I had too high of an impression of LS (and I’m still a fan!). The blogs/tweets I’ve seen from afar made it seem more like a rigorous “be a working software engineer” curriculum. If their candidates are ONLY suited for a node/react stack that seems like a pretty dangerous/inflexible hire. TBF this was for folks who haven’t graduated yet, so maybe they go wider on their final few months. As a person who hires engineers, I don’t want someone who only knows one stack. I want smart people who can solve problems in any stack that gets thrown at them (even if they’re junior and I need to hold their hands a bit).

Raphmedia 7y ago

Unless you are doing things like modifying a Google-style speadsheet of 5000+ columns and rows, you won't see much of a performance loss from using jQuery. It does add a microscopic bit of weight to your page and some milliseconds to your load time, but that's it. It's a ressource that is smaller and faster to load than the content of the page. In my opinion, this argument is meaningless. Modern SPA frameworks are slowing the web way more. Loading your jQuery scripts async will make this transparent for the user. In the edge-cases where jQuery is slower than native JS (because of polyfills, mostly), there's nothing stopping you from using those directly. Unless you are Netflix and micro-optimizing your homepage to the millisecond, there's no hard reason to avoid jQuery. I believe that those slight performance losses are worth the trade for the benefits of using a strong and well tested framework that has browser support and lowers development time. I'd trust non JavaScript experts to use jQuery on my projects, I can't say the same for raw JavaScript. Trend-driven development is a pitfall. Boring technologies are where it's at.