6 ms·

I will personally continue to use jQuery for many years to come. It's a lot of power in few concise lines of code and it really makes sense. And it comes at the

I will personally continue to use jQuery for many years to come. It's a lot of power in few concise lines of code and it really makes sense. And it comes at the cost of a single request. For the small amount of JS my sites use its perfect. I don't know why everyone in thread is saying goodbye to jQuery. Are that many people coding in vanilla JS?

rajangdavis 10y ago
I think it just depends on what type of web application/site you are making. For a simple site, it's probably not that big of a deal to hook in jQuery and write some basic scripts. In my limited experience, if you are writing a Single Page Application, it gets really hard to rationalize changes when everything is hooked in through the DOM. It also gets pretty expensive with mobile browsers as DOM elements carry a huge list of properties and attributes; this why I think libraries like React were made as to have data change and manage state as opposed to the DOM. At the end of the day, the end user and businesses don't care about what technologies that you use, they just want a site that works and can be delivered on time. I just think that with jQuery, there is a lot of cost in terms of making complex changes in the view that other libraries such as React/Angular/Mithril have been designed to get around. These libraries, however, do have a cost in terms of complexity that I think jQuery never really had.
- somecallitblues 10y ago
  I agree with you about jQuery getting quickly out of hand if you want to create something like a one page app and you should certainly use something like React or Angular. I do use it. But to do a quick Ajax post, read some data and display a message or show and hide something jQuery is awesome. To tie a quick event listener to a dropdown and do something or to find children of some element jQuery is still few lines of code that don't even need to be cross browser tested. Using vanilla JS for these things when you can do this in few lines of jQuery code seems masochistic.
  - rajangdavis 10y ago
    I agree to an extent. I think in the example you mention, I would probably do it in vanilla JS. XHR is a negligible amount of code with vanilla javascript. It's also the same thing with event handlers but you do not need the overhead of the entire jQuery library. If you want animations, I would borrow a few CSS declarations from animate.css and add/remove classes or data attributes as needed. I think it really depends on how you structure your HTML as well; having tortured myself into learning Angular has really helped with understanding how to think about data structures as opposed to strict DOM elements and this has carried over to how I write javascript nowadays. One thing that I will mention is that I have worked really hard to not use jQuery over the last year, so my preferences may not be shared by you. I guess it depends on what is quicker and easier to maintain for you.
    - somecallitblues 10y ago
      See you've made an effort to go back to document.getElementBy... where I just wouldn't be able to go back to that after 10 years of such concise syntax that so closely matches CSS. But I'm a bit lazy and tend to find the easiest and quickest way to get to the result.
      - mercer 10y ago
        I find that the current state of things is that, indeed, jQuery is often still worth using, but only just, and especially if older browsers have to be supported. If download size is at all an issue, jQuery is the first thing to go. I have a tiny collection of helper functions that make 'plain js' almost as simple as jQuery in most cases. Almost. For example, at the very least I'll have a '$' helper function that makes document.querySelector(All) simpler/quicker to use, and I use a helper function for events to make it a bit more like $(<selector>).on(). But considering the fact that I have quite a few projects where the client will upload some huge image for the home slideshow or where there's no time or incentive to do any lazy loading of images, jQuery is often still the pragmatic solution. Especially when other devs need to deal with the project at a later stage.
TekMol 10y ago
I use plain JS. Can you give an example of a typical line of jQuery that you prefer over vanilla?
- somecallitblues 10y ago
  See my reply child post. But anything from tying a quick event of any kind to an element and posting a form using Ajax and consuming the response, doing quick show and hide. And the ease of implemting a million different plugins for all kinds of things, from morals to slides, in this jQuery is still a champ.
- adamlett 10y ago
  JQuery still smoothes over browser inconsistencies. For instance, I was recently bit by this: https://connect.microsoft.com/IE/feedback/details/878564/element-classlist-toggle-does-not-support-second-parameter https://connect.microsoft.com/IE/feedback/details/878564/ele...
- mercer 10y ago
  I have an example to which maybe you or someone else can suggest a better 'vanilla' solution. Would love to hear suggestions. With jQuery I'd often do $(<root-element>).on('click', <target element>, callback); crucially, because events bubble up, even a click on a child element of <target element> will register as a click on the target element. in plain js it doesn't seem to work that way. I'd do <root-elem>.addEventListener(), but I'd run into the problem that the event.target would point at the exact element that was clicked on instead of the parent element that I wanted to register clicks on. Given the structure ".item .inner .title", I can't just check if event.target.classList contains 'item', because it might only contain 'title' or 'inner'. event.path to the rescue! I can simply check if any of the parent nodes do contain the 'item' class. Except event.path doesn't work in safari mobile, so it needs a polyfill. Plus on every event handler I have to go up event.path to check. Obviously it's not that hard to write a helper function that basically emulates .on(), but I can't help but feel that I'm maybe missing some simpler, plain solution. Any suggestions?
  - dham 10y ago
deleted 10y ago
[deleted]
lojack 10y ago
Maybe check out Zepto. It aims to have the same API as jQuery without all the debt of supporting older browsers. I still prefer to use jQuery over vanilla JS, but often I'm building apps that'll only be used on evergreen browsers, so that tends to be a better choice for me.

rajangdavis 10y ago

I think it just depends on what type of web application/site you are making. For a simple site, it's probably not that big of a deal to hook in jQuery and write some basic scripts. In my limited experience, if you are writing a Single Page Application, it gets really hard to rationalize changes when everything is hooked in through the DOM. It also gets pretty expensive with mobile browsers as DOM elements carry a huge list of properties and attributes; this why I think libraries like React were made as to have data change and manage state as opposed to the DOM. At the end of the day, the end user and businesses don't care about what technologies that you use, they just want a site that works and can be delivered on time. I just think that with jQuery, there is a lot of cost in terms of making complex changes in the view that other libraries such as React/Angular/Mithril have been designed to get around. These libraries, however, do have a cost in terms of complexity that I think jQuery never really had.

somecallitblues 10y ago
I agree with you about jQuery getting quickly out of hand if you want to create something like a one page app and you should certainly use something like React or Angular. I do use it. But to do a quick Ajax post, read some data and display a message or show and hide something jQuery is awesome. To tie a quick event listener to a dropdown and do something or to find children of some element jQuery is still few lines of code that don't even need to be cross browser tested. Using vanilla JS for these things when you can do this in few lines of jQuery code seems masochistic.
- rajangdavis 10y ago
  I agree to an extent. I think in the example you mention, I would probably do it in vanilla JS. XHR is a negligible amount of code with vanilla javascript. It's also the same thing with event handlers but you do not need the overhead of the entire jQuery library. If you want animations, I would borrow a few CSS declarations from animate.css and add/remove classes or data attributes as needed. I think it really depends on how you structure your HTML as well; having tortured myself into learning Angular has really helped with understanding how to think about data structures as opposed to strict DOM elements and this has carried over to how I write javascript nowadays. One thing that I will mention is that I have worked really hard to not use jQuery over the last year, so my preferences may not be shared by you. I guess it depends on what is quicker and easier to maintain for you.
  - somecallitblues 10y ago
    See you've made an effort to go back to document.getElementBy... where I just wouldn't be able to go back to that after 10 years of such concise syntax that so closely matches CSS. But I'm a bit lazy and tend to find the easiest and quickest way to get to the result.
    - mercer 10y ago
      I find that the current state of things is that, indeed, jQuery is often still worth using, but only just, and especially if older browsers have to be supported. If download size is at all an issue, jQuery is the first thing to go. I have a tiny collection of helper functions that make 'plain js' almost as simple as jQuery in most cases. Almost. For example, at the very least I'll have a '$' helper function that makes document.querySelector(All) simpler/quicker to use, and I use a helper function for events to make it a bit more like $(<selector>).on(). But considering the fact that I have quite a few projects where the client will upload some huge image for the home slideshow or where there's no time or incentive to do any lazy loading of images, jQuery is often still the pragmatic solution. Especially when other devs need to deal with the project at a later stage.

TekMol 10y ago

I use plain JS. Can you give an example of a typical line of jQuery that you prefer over vanilla?

somecallitblues 10y ago
See my reply child post. But anything from tying a quick event of any kind to an element and posting a form using Ajax and consuming the response, doing quick show and hide. And the ease of implemting a million different plugins for all kinds of things, from morals to slides, in this jQuery is still a champ.
adamlett 10y ago
JQuery still smoothes over browser inconsistencies. For instance, I was recently bit by this: https://connect.microsoft.com/IE/feedback/details/878564/element-classlist-toggle-does-not-support-second-parameter https://connect.microsoft.com/IE/feedback/details/878564/ele...
mercer 10y ago
I have an example to which maybe you or someone else can suggest a better 'vanilla' solution. Would love to hear suggestions. With jQuery I'd often do $(<root-element>).on('click', <target element>, callback); crucially, because events bubble up, even a click on a child element of <target element> will register as a click on the target element. in plain js it doesn't seem to work that way. I'd do <root-elem>.addEventListener(), but I'd run into the problem that the event.target would point at the exact element that was clicked on instead of the parent element that I wanted to register clicks on. Given the structure ".item .inner .title", I can't just check if event.target.classList contains 'item', because it might only contain 'title' or 'inner'. event.path to the rescue! I can simply check if any of the parent nodes do contain the 'item' class. Except event.path doesn't work in safari mobile, so it needs a polyfill. Plus on every event handler I have to go up event.path to check. Obviously it's not that hard to write a helper function that basically emulates .on(), but I can't help but feel that I'm maybe missing some simpler, plain solution. Any suggestions?
- dham 10y ago

deleted 10y ago

[deleted]

lojack 10y ago

Maybe check out Zepto. It aims to have the same API as jQuery without all the debt of supporting older browsers. I still prefer to use jQuery over vanilla JS, but often I'm building apps that'll only be used on evergreen browsers, so that tends to be a better choice for me.