6 ms·
jQuery is still my bread and butter for DOM manipulation and events. I've found it to be much more readable than vanilla JS.
by BlameKaneda 5y ago
jQuery is still my bread and butter for DOM manipulation and events. I've found it to be much more readable than vanilla JS.
- thehappypm 5y agoI just use vanilla JS now, but it took a while to get there.
- deleted 5y ago[deleted]
- onion2k 5y agoThat's 30KB over the network and 90KB of JS code in memory so that you don't need to learn about 5 standardized browser API methods that are the same in every browser going back to IE9 then. No doubt that gives you a better developer experience but I don't think your users are thanking you.
- dageshi 5y agoThe internets users managed to live with this terrible 30k burden in the late 2000's when it was the only choice. I think probably in 2021 when 30kb is a rounding error on page sizes they can also probably manage it.
- ducharmdev 5y agoThis feels like a false equivalence; how many of those 2000s users were browsing the web on mobile compared to today?
- dageshi 5y agoDoes 30kb of js really matter on modern phones and modern mobile internet?
- recursive 5y agoIf "modern" means fast, then no. If "modern" means what people are using in 2021, then possibly.
- AnIdiotOnTheNet 5y agoThis kind of thinking is why software continues to get slower and slower despite incredible advances in hardware.
- ducharmdev 5y agoBingo. 30kb doesn't seem like much, but its easy to think it doesn't matter when viewing one dependency in isolation. But if you say "it's just x kb" to all dependencies, then you have a problem when they're all aggregated. This is why I appreciate Svelte's take: with a compiler-heavy approach, you can have a great dev experience without saddling your users with extra dependencies.
- jhgb 5y agoSince many people seem to be religious today about which "packer" is the best and that using one in the first place is a necessity, the answer is apparently "yes".
- liquidise 5y agoI don’t follow. Is the implication here that users can identify an experience difference cause by a 30KB over-the-wire asset, or more, a 90KB in memory one? I know I certainly wouldn’t claim to have that ability myself even on low quality networks.
- onion2k 5y agoIf you're a user on a spotty mobile connection in a rural location on a low-end device ... both.
- gpvos 5y agoIn that case, most of the web is unusable nowadays, and jQuery is not your main problem. Maybe your argument is valid in less-developed countries where more people have spotty connections and more websites have adapted to that (but I wouldn't know, sorry).
- basilgohar 5y agoI'm not happy about it, but the reality is that 120kB is small potatoes in the modern web world. Would it be better without, sure? But there are bigger fish to fry. If jQuery helps the developer achieve their design and development goals, that will play out better for the end-user. It's not ideal, but it's realistic.
- onion2k 5y agoIf jQuery helps the developer achieve their design and development goals, that will play out better for the end-user. That's not the dilemma though. Developer can build solutions without jQuery. They'll be faster, smaller, and have fewer dependencies. Plus, if you're only using jQuery for DOM and events then it probably isn't helping you. Those are two areas where writing vanilla JS is can often be easier than writing the jQuery code to do the same job.
- handrous 5y agojQuery versus vanilla DOM is slower, larger, and adds dependencies. jQuery versus [framework of the month] is "faster, smaller, and [has] fewer dependencies". Simpler build, too, while still keeping you from having to worry about which browser supports what. Depends on what the most likely alternative is, then.
- onion2k 5y agoThere are plenty of modern frameworks that are smaller than jQuery (svelte, Preact, etc). In some apps they may also be faster. If you pick svelte there's the same number of dependencies.
- legitster 5y ago30kb is pretty trivial. And even so, if you are using a CDN like you should the jQuery is likely already cached on the user device.
- saturn_vk 5y agoI recall an earlier discussion on here stating that using CDN nowadays doesn't have any gains, only drawbacks.
- onion2k 5y agoThis is correct. It's called cache partioning. https://developers.google.com/web/updates/2020/10/http-cache-partitioning https://developers.google.com/web/updates/2020/10/http-cache...
- dspillett 5y ago> That's 30KB over the network and 90KB of JS code in memory A fair point, but compared to the payload of most sites (let alone apps) these days that is chicken feed. Just opened that page itself and DevTools tells me 5.2Mb was transferred including ~175KB of JS from twitter, 65Kb JS for the video player (which seems to have 46Kb worth of css associated with it!), ~1Mb worth of font resource, ... > so that you don't need to learn about 5 standardized browser API methods That and the way jQuery does method chaining, which a lot of people find far more convenient, but other features. jQuery does a lot more than querySelector/querySelectorAll/friends. > No doubt that gives you a better developer experience* <attenborough>And here we see a forum commenter in its natural habitat, hunting the point. It sidles up slowly, and pounces...</attenborough> (with apologies for failing to resist being facetious and slightly dickish there) >* but I don't think your users are thanking you.* I don't think most users will notice. Those that do due to slow connections, metered connections, low-power/low-memory devices, etc, are going to baulk at much more before even noticing jQuery on this site. On something like HN (23.8K transferred for this page before my comment was added) 30Kb might look chunky, but few sites are remotely close to being as lean as HN.
- onion2k 5y ago(with apologies for failing to resist being facetious and slightly dickish there) No apology necessary. That was funny. Because it's true. :)
- thrower123 5y agoWho cares when you're slurping down 40 megapixel PNGs for images that are sized with CSS to 100px x 100px?
- lobstrosity420 5y agoCan you elaborate on what JQuery does for you that you can't do with modern JS features such as fetch and query selectors?
- mschuetz 5y agoThis page gives a pretty good overview of why jQuery is still relevant: http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/ Requests have gotten better with "fetch", but unfortunately, the "modern" DOM API is quite bad in some parts, making lots of stuff unnecessarily verbose. On top of that, it's really odd that the DOM API is not compatible with for-of loops, which could have been a selling point.
- lobstrosity420 5y ago>it's really odd that the DOM API is not compatible with for-of loops, which could have been a selling point. I'm not sure what you mean by that? querySelectorAll returns an iterable. Also, your link is outdated. It doesn't include the fetch API which has enjoyed wide support for quite a while now.
- mschuetz 5y ago> I'm not sure what you mean by that? querySelectorAll returns an iterable. Apparently my knowledge is outdated. Last time I tried to switch from jQuery to vanilla JS, the results of document.getElementsByTagName and others were not iterable with for-of.
- legitster 5y agoFor me, the code is easily 10x more readable than vanilla JS. And much shorter, so I can hand code everything quicker without typos.
- BlameKaneda 5y agoTo use an example, I'd much rather do $(".elements").css("color", "red") versus var selector = document.getElementsByClassName('elements'); selector.style.color = 'red';