Hacker News Reader

Comment by rajangdavis | Hacker News Reader

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.

View on HN

> XHR is a negligible amount of code with vanilla javascript

That was one of the pains the Fetch API cured for me. The syntax and overall concept is just so much nicer.

I was using Nanoajax library before that. It's great (and light, 620 bytes gzipped), but I moved almost completely to Fetch as soon as i started getting used to Promises more.

I guess libs like these and maybe even the Fetch in current browsers were somehow inspired by jQuery's $.ajax…

Definitely, I totally agree jQuery did a lot of good in terms of making javascript easier to work with as well as influencing the current spec. I completely forgot about Fetch! Thanks for bringing that up, been too lost in the pre-ES6 syntax.

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.

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.

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.

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.

Reply on news.ycombinator.com