Conversely, looking at how you do it through jQuery after seeing how it is in Javascript gives me the same reaction.

The fact that jQuery is usually assigned to the dollar sign definitely doesn't help, especially for beginners. The amount of questions I've answered that stemmed from a fundamental misunderstanding of how Javascript works, all because they learned jQuery instead of Javascript, is pretty significant.

I remember when I was in uni that the $() must've had a special meaning or something. I was pretty convinced that the $ was some tough mathematical operator or computer science concept that I didn't yet understand.

When I learned that it was simply a function invocation that returned a jQuery object so you could chain it, I was absolutely shocked about the simplicity of that statement.

Beginning developers sure like to project their cognitive insecurities onto programming. Or at least, I did :)

There's so much magic in programming that as a beginner, it's hard to know which magic you should dig deeper into, vs which is such a treacherous rabbit hole you're better off cargo culting.

It think this is true of many technical things. Statistics, sailing, car mechanics, photography... What I love about HN is it often gives clues as to which are the interesting rabbit holes.

That argument stands true for most frameworks on most platforms. I prefer the dollar sign; it's pervasive and concise.

I disagree. There's nothing about React, Vue or any other framework that I'm aware of that does anything similar to jQuery's dollar sign. The only magically-looking abstraction I can think of is JSX, and that's not only not mandatory but very obviously something that's off the curve. Unlike the dollar sign, which just looks like a special construct of the language.

Svelte uses the dollar sign. https://svelte.dev/tutorial/reactive-declarations

Wow, that looks weird. Thank you, I hadn't heard of Svelte before.

No one blames you for not knowing about the 18275th javascript framework.

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.

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.

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(...)

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 :)

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

How so? Who stops you from doing something like `const $ = document.querySelector`?

There's a ton of other functions you need like element.addEventListener, insertAdjacentElement, XMLHttpRequest (when you need progress) etc. etc. At that point you might as well save yourself and the person after you a major headache and just use jQuery whose API everybody knows.

The big magic of jQuery is that you can act on an array of elements as if it were a single element. Your alias does not give you that at all.

Good point

I'm still a little bit sad we got fetch as part of javascript when the request module had such a great interface. I still prefer the look of it.

https://www.npmjs.com/package/request

> The Javascript document API is super verbose.

Can't say I've ever heard that as an issue before..

Also I think the main point was there are so many better frameworks that manage the DOM better than jQuery as the need has evolved. I'll always have fond memories of jQuery but I don't see it as my go-to anymore, by a long shot.