3 ms·

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 writ

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.
      - douche 10y ago
        I can't help but think the obsession with download size of script files in the JavaScript community is a bizarre premature optimization. I'm saving 400 kb by dropping useful library XYZ. Meanwhile, the page is loading 47 different snippets of non-async advertising and tracking code, social media buttons, non-optimized full-size PNG images, auto-playing videos, and more useless resources that dwarf any amount of JavaScript code.
        cmg 10y ago
        I think that's a bit of a non-sequitur. Many people are focusing on performance in more areas than just dropping "useful" libraries - moving to async ads and tracking (if they have any), optimizing images, using SVG, etc. Besides, 400k of (blocking) JavaScript can be the difference between the site loading quickly on mobile and the user giving up.

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.
    - douche 10y ago
      I can't help but think the obsession with download size of script files in the JavaScript community is a bizarre premature optimization. I'm saving 400 kb by dropping useful library XYZ. Meanwhile, the page is loading 47 different snippets of non-async advertising and tracking code, social media buttons, non-optimized full-size PNG images, auto-playing videos, and more useless resources that dwarf any amount of JavaScript code.
      - cmg 10y ago
        I think that's a bit of a non-sequitur. Many people are focusing on performance in more areas than just dropping "useful" libraries - moving to async ads and tracking (if they have any), optimizing images, using SVG, etc. Besides, 400k of (blocking) JavaScript can be the difference between the site loading quickly on mobile and the user giving up.