9 ms·

We are, indeed, in a world where Jquery is now the preferable choice. Frontend development is going through what video games went through in the 80s, so much ne

We are, indeed, in a world where Jquery is now the preferable choice. Frontend development is going through what video games went through in the 80s, so much new shovelware every day that people are eventually going to get tired of it.

yashg 3y ago
Few days back I became aware of youmightnotneedjquery.com so we can even do away with jquery.
amiga-workbench 3y ago
jQuery is completely unnecessary now, you can use the built in element selectors to do all the same stuff without pulling a huge lib in. The value in jQuery was acting as a shim to smooth over IE's deficiencies back in the day. Now, its a waste of bandwidth.
- zelphirkalt 3y ago
  Still preferable over how most SPAs are written these days, especially when looking at overhead.
- distantsounds 3y ago
  yeah, I'm very glad that we have a dozen and a half Javascript libraries that aren't jQuery instead!
  - danShumway 3y ago
    GP isn't saying you should use React, they're saying that if you don't need React you probably don't need jQuery either and you might as well just use pure Javascript. Most of the functions people used jQuery for are natively supported in every major browser that runs Javascript, and the few that aren't have decent polyfills. I mean, let's be real; most of what people were using jQuery for was stuff like `querySelector`, `closest`, `classList`, etc... For those people, pure Javascript is JQuery now. If you don't want a framework and you don't want reactive/declarative interfaces, then you probably don't need a library. I would say the same thing (maybe to a lesser degree) about "standard" libraries like Lodash. Native Javascript has a `reduce` function now, it's widely supported. And if you have to target any of the very few browsers that don't have it, then polyfilling is (usually) the better choice. See also Blueberry and promises; just use JS promises, they're fine.
    - gunapologist99 3y ago
      bluebird?
      - danShumway 3y ago
        Yep, good catch :) It's been a while since I ran into it.
- ipaddr 3y ago
  jQuery is a few kilobytes not some huge libruary. You can do it n pure js but jQuery allows you to do it in less lines of code and cleaner.
  - capableweb 3y ago
    There are only a few cases where that's true today. Probably 90% of the functions that helped a lot before have been implemented by browsers natively today.
    - rchaud 3y ago
      So? The jQuery code still works regardless of when the browser decided to catch up. I picked up jQuery because JS in browsers weren't cross-compatible for ages. I don't see a need to stop unless jQuery stops being cross-compatible.
      - capableweb 3y ago
        > So? The jQuery code still works regardless of when the browser decided to catch up. So, it's not needed anymore. I also started using jQuery in order to get cross-browser support for handy stuff, but since that stuff is now cross-browser without using any 3rd party libraries at all, there is no need to use extra bandwidth and CPU cycles from your users to download something that basically already exists.
        rchaud 3y ago
        Most of the world's bandwidth is being used to stream Netflix and Youtube. I think the web will be OK if my site sends a network request for an 87KB script every now and then.
        guggle 3y ago
        I never undertood the fuss with bandwidth and jquery either... it's only 30k once behind mod_deflate. To put it in perspective, vue.global.js is 463k or 104k once gzipped. There are many reason not to use Jquery for greenfield projects now, but bandwith is not one of them.
- tambourine_man 3y ago
  jQuery was a browser normalization layer and one heck of an API for DOM manipulation. The first is thankfully not needed anymore, the second hasn’t been matched in simplicity and power by the native one, unfortunately. Not by a long shot. If you don’t believe me, check out one of the “You Might Not Need jQuery” sites. They read much like “you might not need firelighter, stones and sticks are all you need”.
  - gunapologist99 3y ago
    to be honest, I don't use jquery either, but https://youmightnotneedjquery.com/ https://youmightnotneedjquery.com/ seems to be telling me that I might just need jquery if I want the code to be concise and readable. EDIT: oh, I just realized that's exactly what you were saying!
    - tambourine_man 3y ago
      Yeah, I always find it hilarious that it ends up showing that you may not need it but it sure is nice to have.
- jermaustin1 3y ago
  In my professional life, I use jQuery daily, in my personal projects, almost never. BUT that doesn't mean jQuery doesn't have certain niceties that plain-old javascript doesn't. But implementing them in modern javascript is only a few lines of code, so I end up with my own micro-jquery usually by the end of a project, because I will implement a feature from jQuery I like that doesn't exist (or at least, that I don't know about). I usually do something like: const $ = function(selector) { }; at the start of every project, implement document.querySelectorAll, then return an object with a handful of functions like on(event, callback), off(event), one(event, callback), attr/data/prop(name[, value]). All of them are basically just tiny <10 LOC shims for a lot of built-in functionality. But that way I still get the niceness/terse-ity of jQuery, but not the bloat and overhead of it being able to still do: $('.selector').one('submit', () => false) is a lot nicer than document.querySelector('.selector).addEventListener('submit', () => false, {once:true}).
- rchaud 3y ago
  It's at 87KB these days for the minified production version. There are corporate logo PNGs that are bigger in size.
  - amiga-workbench 3y ago
    That's larger than all of the JS business logic in most of my applications and comparable to some of my stylesheets. For mobile users it all adds up, and not everybody has fantastic reception all the time. You're not wrong about logos, but I find that webp will often squish that sort of thing down to 10-15k.
herbst 3y ago
I agree. There is no bandwidth wasted when using a popular CDN just drop it in and enjoy the simplicity it still ads to the already nice as well JavaScript methods.
- jdsleppy 3y ago
  It's fine if you don't want to call it a waste of bandwidth, but bandwidth is definitely still used because browsers don't share caches between domains https://www.stefanjudis.com/notes/say-goodbye-to-resource-caching-across-sites-and-domains/ https://www.stefanjudis.com/notes/say-goodbye-to-resource-ca....
  - ipaddr 3y ago
    Silly point as jQuery is a few kilobytes meanwhile your custom font is a few megs.
    - mcpeepants 3y ago
      It’s not a silly point. It’s clarifying a misconception that was long used as an argument for using CDNs to deliver script assets like jQuery, which was being repeated here in context.
    - danShumway 3y ago
      I feel like if you are worried about 30kb, you're probably also not using custom fonts; or you're at least not blocking rendering behind them (you're accepting FOUT). It's a reasonable argument to make that minimizing 3rd-party library use is premature optimization for most websites, but if you get to the point where you need that optimization then it is 30kb and it won't be cached (CDN caching is a myth, CDNs are only useful for minimizing server load/response-time they aren't shared between domains) and it will block your initial app logic.
      - TylerE 3y ago
        You're making the assumption that the developer has any input in the matter.
arghwhat 3y ago
Whether or not there is shovelware in frontend development is irrelevant: jQuery provides little to nothing over regular vanilla JS nowadays.
tmpX7dMeXU 3y ago
[flagged]
njovin 3y ago
I really enjoy using alpine.js. It gives me dead-simple lightweight DOM manipulation with much less code than vanilla JS or jQuery and doesn't require any build systems.

yashg 3y ago

Few days back I became aware of youmightnotneedjquery.com so we can even do away with jquery.

amiga-workbench 3y ago

jQuery is completely unnecessary now, you can use the built in element selectors to do all the same stuff without pulling a huge lib in. The value in jQuery was acting as a shim to smooth over IE's deficiencies back in the day. Now, its a waste of bandwidth.

zelphirkalt 3y ago
Still preferable over how most SPAs are written these days, especially when looking at overhead.
distantsounds 3y ago
yeah, I'm very glad that we have a dozen and a half Javascript libraries that aren't jQuery instead!
- danShumway 3y ago
  GP isn't saying you should use React, they're saying that if you don't need React you probably don't need jQuery either and you might as well just use pure Javascript. Most of the functions people used jQuery for are natively supported in every major browser that runs Javascript, and the few that aren't have decent polyfills. I mean, let's be real; most of what people were using jQuery for was stuff like `querySelector`, `closest`, `classList`, etc... For those people, pure Javascript is JQuery now. If you don't want a framework and you don't want reactive/declarative interfaces, then you probably don't need a library. I would say the same thing (maybe to a lesser degree) about "standard" libraries like Lodash. Native Javascript has a `reduce` function now, it's widely supported. And if you have to target any of the very few browsers that don't have it, then polyfilling is (usually) the better choice. See also Blueberry and promises; just use JS promises, they're fine.
  - gunapologist99 3y ago
    bluebird?
    - danShumway 3y ago
      Yep, good catch :) It's been a while since I ran into it.
ipaddr 3y ago
jQuery is a few kilobytes not some huge libruary. You can do it n pure js but jQuery allows you to do it in less lines of code and cleaner.
- capableweb 3y ago
  There are only a few cases where that's true today. Probably 90% of the functions that helped a lot before have been implemented by browsers natively today.
  - rchaud 3y ago
    So? The jQuery code still works regardless of when the browser decided to catch up. I picked up jQuery because JS in browsers weren't cross-compatible for ages. I don't see a need to stop unless jQuery stops being cross-compatible.
    - capableweb 3y ago
      > So? The jQuery code still works regardless of when the browser decided to catch up. So, it's not needed anymore. I also started using jQuery in order to get cross-browser support for handy stuff, but since that stuff is now cross-browser without using any 3rd party libraries at all, there is no need to use extra bandwidth and CPU cycles from your users to download something that basically already exists.
      - rchaud 3y ago
        Most of the world's bandwidth is being used to stream Netflix and Youtube. I think the web will be OK if my site sends a network request for an 87KB script every now and then.
        guggle 3y ago
        I never undertood the fuss with bandwidth and jquery either... it's only 30k once behind mod_deflate. To put it in perspective, vue.global.js is 463k or 104k once gzipped. There are many reason not to use Jquery for greenfield projects now, but bandwith is not one of them.
tambourine_man 3y ago
jQuery was a browser normalization layer and one heck of an API for DOM manipulation. The first is thankfully not needed anymore, the second hasn’t been matched in simplicity and power by the native one, unfortunately. Not by a long shot. If you don’t believe me, check out one of the “You Might Not Need jQuery” sites. They read much like “you might not need firelighter, stones and sticks are all you need”.
- gunapologist99 3y ago
  to be honest, I don't use jquery either, but https://youmightnotneedjquery.com/ https://youmightnotneedjquery.com/ seems to be telling me that I might just need jquery if I want the code to be concise and readable. EDIT: oh, I just realized that's exactly what you were saying!
  - tambourine_man 3y ago
    Yeah, I always find it hilarious that it ends up showing that you may not need it but it sure is nice to have.
jermaustin1 3y ago
In my professional life, I use jQuery daily, in my personal projects, almost never. BUT that doesn't mean jQuery doesn't have certain niceties that plain-old javascript doesn't. But implementing them in modern javascript is only a few lines of code, so I end up with my own micro-jquery usually by the end of a project, because I will implement a feature from jQuery I like that doesn't exist (or at least, that I don't know about). I usually do something like: const $ = function(selector) { }; at the start of every project, implement document.querySelectorAll, then return an object with a handful of functions like on(event, callback), off(event), one(event, callback), attr/data/prop(name[, value]). All of them are basically just tiny <10 LOC shims for a lot of built-in functionality. But that way I still get the niceness/terse-ity of jQuery, but not the bloat and overhead of it being able to still do: $('.selector').one('submit', () => false) is a lot nicer than document.querySelector('.selector).addEventListener('submit', () => false, {once:true}).
rchaud 3y ago
It's at 87KB these days for the minified production version. There are corporate logo PNGs that are bigger in size.
- amiga-workbench 3y ago
  That's larger than all of the JS business logic in most of my applications and comparable to some of my stylesheets. For mobile users it all adds up, and not everybody has fantastic reception all the time. You're not wrong about logos, but I find that webp will often squish that sort of thing down to 10-15k.

herbst 3y ago

I agree. There is no bandwidth wasted when using a popular CDN just drop it in and enjoy the simplicity it still ads to the already nice as well JavaScript methods.

jdsleppy 3y ago
It's fine if you don't want to call it a waste of bandwidth, but bandwidth is definitely still used because browsers don't share caches between domains https://www.stefanjudis.com/notes/say-goodbye-to-resource-caching-across-sites-and-domains/ https://www.stefanjudis.com/notes/say-goodbye-to-resource-ca....
- ipaddr 3y ago
  Silly point as jQuery is a few kilobytes meanwhile your custom font is a few megs.
  - mcpeepants 3y ago
    It’s not a silly point. It’s clarifying a misconception that was long used as an argument for using CDNs to deliver script assets like jQuery, which was being repeated here in context.
  - danShumway 3y ago
    I feel like if you are worried about 30kb, you're probably also not using custom fonts; or you're at least not blocking rendering behind them (you're accepting FOUT). It's a reasonable argument to make that minimizing 3rd-party library use is premature optimization for most websites, but if you get to the point where you need that optimization then it is 30kb and it won't be cached (CDN caching is a myth, CDNs are only useful for minimizing server load/response-time they aren't shared between domains) and it will block your initial app logic.
    - TylerE 3y ago
      You're making the assumption that the developer has any input in the matter.

arghwhat 3y ago

Whether or not there is shovelware in frontend development is irrelevant: jQuery provides little to nothing over regular vanilla JS nowadays.

tmpX7dMeXU 3y ago

[flagged]

njovin 3y ago

I really enjoy using alpine.js. It gives me dead-simple lightweight DOM manipulation with much less code than vanilla JS or jQuery and doesn't require any build systems.