Hacker News Reader

Comment by cphoover | Hacker News Reader

You don't have to use all of it though, right? You can choose to only only use the applicable parts: eg:

``` $('.container-element') .addClass('active');

// vs

document.querySelectorAll('.my-class-selector') .classList.add('active') ```

I use the native APIs all the time, they are not that complicated or overly verbose. Easily memorized with practice IMHO. Also they are all extremely well documented on MDN.

View on HN

Technically that breaks, you want:

    document.querySelectorAll('.my-class-selector').forEach(el => el.classList.add('active'))

Personally I use the native APIs because they aren't that hard to use (most of them, anyways) and I tend to be OCD about bundle sizes, but to each their own, I suppose.

Yeah, oh so many years ago I realized that I use just a small subset of jQuery, and just rewrote those bits, to avoid having to inject whole of jQuery into all pages that I browse (I had some global https?://* userscripts, so I was basically injecting jQuery into every single page and frame).

https://megous.com/dl/tmp/basic.js

1.3kB compressed. Much better. :) And I avoided having to rewrite my extensions with platform APIs. That was before FF killed all the joy in writing userscripts for me, because I was no longer able to install and update them just by copying them to mozilla folder and had to invoke a lot of clicking ceremony to just get my 20 scripts or so from git into firefox past the webextension limitations on storage/access to mozilla folder.

You should totally open-source that, put it on NPM, and write an article or so about it.

Everyone will have different set of methods they use. Point of this is that if you need some method you can just add it in in 4-5 lines or remove one you don't need. So it's not the best fit for NPM. It's good fit for good old copy/paste into a project, if you're optimizing for size/memory use. :)

BTW, NodeList.prototype.forEach is not available on every browsers that supports querySelector/querySelectorAll, such as IE11: https://caniuse.com/mdn-api_nodelist_foreach

So you need to be careful about writing code like that if you want to avoid jQuery.

We just don’t bother supporting IE11.

you are probably in smaller company. still at least 1 percent of users use it. 1% of revenue increase in big companies is substantial amount of money

Your example does not work. querySelectorAll returns array and you can't write `array.classList.add("...")`, because array does not have that property. You need to iterate over that array. And that's exactly why jQuery is so much more convenient over native API: you can just treat collections of elements like an element and jQuery will iterate for you if necessary.

Another jQuery advantage is pseudo-selectors which don't exist in CSS.

There are plenty of convenient one-liners in jQuery which will expand to plenty of lines in native API. That said, with modern API and JS features it's not that bad either.

querySelectorAll returns a NodeList, which is even more limited than an array (e.g. no map or filter).

but [...querySelectorAll()] does return an array and is just as concise

but beware of ASI :)

Just a nitpick, but querySelectorAll returns a NodeList.

This can bite at times, for example IE supports Array.forEach, but not NodeList.forEach

Yeah this gets me every time. You can .forEach a NodeList, but can't .map. I usually end up wrapping it in an array and calling map on it like [...theNodeList].map(...)

I think the fact that your very simple example (which is already longer and more complicated in your version) doesn't work shows the advantage of jQuery

Isn’t your example a type error. JQuery’s operations auto-broadcast over the lists of elements it returns whereas the native methods don’t

Reply on news.ycombinator.com