Use $ & $$ Instead of document.querySelector/All in JavaScript without jQuery

If you work on a distributed team or with legacy code, and considering the potential for conflict (mostly with jQuery but some other libraries, and any code where someone may have used $ for document.getElementById(), as used to be common), I think it'd be a good idea to use trivially longer identifiers like this:

const $q = document.querySelector.bind(document);
const $qa = document.querySelectorAll.bind(document);

This is similar to a common method of using jQuery in noConflict mode, e.g.:

const $j = jQuery.noConflict();

It could be judiciously extended for similar methods if you use them often enough.

I have been using
$ = function(e) {return document.getElementById(e)}
for years. Now I started using
$ = function(e) {
switch (e[0]) {
case '.': return document.getElementsByClassName(e.substring(1, e.length)); break;
case '#': return document.getElementById(e.substring(1, e.length)); break;
default: return document.getElementsByTagName(e);
}
}

Chrome has its own Console Utilities API Reference where $ and $$ are offered regardless, among other utils, unless the global scope has been overwritten with something else (i.e. jQuery).

The API for $ and $$ is more jQuery-ish, and if you'd like to reproduce it its like:

const $ = (css, parent = document) => parent.querySelector(css);
const $$ = (css, parent = document) => parent.querySelectorAll(css);

To avoid needing polyfills for forEach or Symbol.iterator on NodeList collections, you can also go ahead and convert the static collection as Array so that all methods, including filter and map can be used.

const $$ = (css, parent = document) =>
  Array.from(parent.querySelectorAll(css));

If you don't have Array.from in your debug session, or you are after a thin layer that works across browsers, you can go for the following:

function $(css, parent) {
  return (parent || document).querySelector(css);
}

function $$(css, parent) {
  var nodes = (parent || document).querySelectorAll(css);
  return Array.prototype.slice.call(nodes, 0);
}

Watch out that querySelectorAll returns a NodeList object, whereas $$ in the console returns an array.

So if you're used to call all the sweet array prototype methods, you might fall short!

Solution: wrap everything in Array.from.

This is my take on it. It checks whether I'm asking for an id or not, and if I am, it returns just that one element. If not, the NodeList is made into an array.

const $ = (q, d = document) => 
  /#\S+$/.test(q)                       // check if query asks for ID
  ? d.querySelector.bind(d)(q)          // if so, return one element
  : [...d.querySelectorAll.bind(d)(q)]  // else, return all elements in an array.

I'm using document.querySelectorAll for all elements. Even for id elements.

Actually, you can use querySelectorAll for id elements. It will work for one element. There must not be multiple elements in a document that have the same id value.

const $ = document.querySelectorAll.bind(document)

const testEl = $("#test")

testEl.forEach(el => {
    console.log(el)
})

Instead of using 2 different constants, what about checking the length of the selector first like this:

const $ = s => document.querySelectorAll.bind(document)(s).length > 1 ? document.querySelectorAll.bind(document)(s) : document.querySelector.bind(document)(s);

or something like that to make it much more similar to jQuery $?

Ugh, I had to replace jQuery in our app with a work-a-like jQuery that I wrote. It was THE WORST, because I had to learn jQuery, then I learned all about jQuery's internals, then I had to figure out the subset of jQuery that we depended upon that did not have all the internal state that jQuery had (did everyone know jQuery has a ton of internal state?), then I had to put up with all the upset other JavaScript developers who complained about my not-jQuery not behaving like jQuery when they added new code that relied on jQuery-isms that I hadn't implemented because the prior versions of the code hadn't relied upon those facilities (so I didn't bother to implement them).

What a royal pain in the keester.

I wish I had the foresight to just do your $ and $$ bindings and tell all the other devs to suck it up. Your solution is GENIUS.

I'm interested in your thoughts a little deeper on this:

"I advocate modern JavaScript. Because it's super awesome." - Why would you advocate modern JavaScript ahead of jQuery beyond it being awesome. What do you feel is the main selling point is that can't be accomplished in other ways?