querySelector vs getElementById

They answer different questions, and they are not interchangeable. GetElementById takes an exact element id and returns that one element or null. QuerySelector takes a full CSS selector, so it can match by tag, by class, by attribute or by any combination, and it returns the first match in document order.

For a plain id lookup, getElementById is the right tool. It is a direct hash lookup rather than a selector match, so it is faster and it never throws. If the id does not exist you get null.

For everything else, querySelector is the better tool. It expresses intent in one string, and the selector syntax means you can do things that have no equivalent with getElementById, such as finding the first element with a given class or the first list item inside a particular list.

There is one classic mistake to warn about. The older getElementsByClassName and getElementsByTagName methods return a live collection, which is a live HTMLCollection that updates as the page changes. It is not a real array, it has no forEach method, and iterating it while changing the page can produce surprising results. The querySelectorAll method returns a static array instead, which is almost always what you want.

Two more notes for an interview. The getElementById method only works with an id attribute, and putting the same id on two elements is invalid markup even though the method would return the first one. And when you need many elements, querySelectorAll is the answer, returning an array you can loop over with forEach or map.

It throws a SyntaxError, and the error happens before any element is searched for. This is a genuine difference from getElementById, which accepts any string and simply looks for a matching id.

// The DOM only exists in a browser, so check before using it.
if (typeof document !== "undefined") {
  console.log(document.getElementById("app"));   // null if there is no such id
  console.log(document.querySelector("#app"));    // null as well

  try {
    document.querySelector("div:::bad");
  } catch (err) {
    console.log(err.name);   // "SyntaxError"
  }

  // The first match wins, and you can scope the search.
  console.log(document.querySelector("ul li"));    // the first li inside any ul
  console.log(document.querySelectorAll("li").length);

  // A null result is not an error - check it before you use it.
  const panel = document.querySelector("#panel");
  if (panel) {
    panel.classList.add("ready");
  }
} else {
  console.log("No DOM in this runtime - open a browser console to try it.");
}

That behaviour is deliberate. A malformed selector is a programming error rather than a missing element, and silently returning nothing would hide it. The flip side is that a selector built from user input is a runtime hazard: if the user can inject characters that break the selector syntax, you get an exception rather than a result.

The safe pattern is to keep user input out of the selector string and use an attribute selector with a quoted value instead, or to select a stable container first and then look for children by comparing their attribute values in JavaScript.

Two related details. The querySelectorAll method throws on an invalid selector too, and the returned collection is static, so it does not change when the page does. And the closest method is worth knowing, because it walks up from a starting element to find the nearest ancestor that matches a selector, which is the usual way to handle a click on something nested inside a clickable row.