What are the key differences between NodeList and HTMLCollection?
Tests DOM snapshot vs live binding: querySelectorAll returns a static NodeList, getElementsByTagName returns a live HTMLCollection. Strong answers note childNodes is a live NodeList and warn against caching length during DOM mutation.
What's really being asked
Whether you understand the DOM collection contract and the performance and correctness implications of live versus static snapshots. Interviewers care if you know which APIs return live references that mutate underneath you and which return point-in-time copies, because this directly affects loop correctness, memory churn, and bug surface area in real applications.
The full answer
First, the core distinction that querySelectorAll returns a static NodeList while getElementsByTagName returns a live HTMLCollection. Second, that live collections automatically reflect DOM changes, so adding or removing nodes updates the collection immediately, whereas a static NodeList does not. Third, that NodeList has a nuanced exception: Node.childNodes is live, making it an important counterexample to the assumption that all NodeLists are static. Fourth, practical iteration advice, such as avoiding cached length variables when mutating a live collection inside a loop because the index boundaries shift dynamically. Fifth, that neither type is a true JavaScript array, but modern NodeLists support forEach and can be converted with Array.from.
The mistakes people make
Claiming that every NodeList is static or that every NodeList is live. Asserting that querySelectorAll updates automatically when the DOM changes. Treating an HTMLCollection or NodeList as a full array and attempting to use methods like map or filter directly without conversion. Suggesting that live collections are always superior for performance without acknowledging their mutation hazards. Failing to mention childNodes as a live NodeList.
What usually comes next
How would you safely remove every other element from a live HTMLCollection? When is it better to use a static NodeList over a live collection in a long-running component? What happens to iteration if you append a node inside a for loop over childNodes? Can you explain the historical reason NodeList exists alongside array-like structures in modern APIs?
A concrete example
Imagine a parent element with two children. Calling parent.childNodes gives a live NodeList with length two. If you then call parent.appendChild to add a div, the same childNodes reference now reports length three without being reassigned. By contrast, calling document.querySelectorAll on those children returns a static NodeList with length two. Appending another matching child later leaves the original querySelectorAll result at length two, proving it captured a snapshot at the moment of the query.
Interview question
After storing parent.childNodes in a variable, a developer appends a new child and sees the stored length increase without reassignment. What explains this?
- a.Browsers silently replace the referenced object when the DOM changes, making all collections dynamic.
- b.Only HTMLCollections are live, so childNodes must be an HTMLCollection rather than a NodeList.
- c.All NodeLists are live, so querySelectorAll would behave the same way.
- d.The stored reference is a live NodeList, but querySelectorAll returns a static snapshot that would not update.Correct
Why? this is the answer
childNodes is a live NodeList that mutates in place, while querySelectorAll returns a static snapshot that never updates. A is tempting because many developers assume all NodeLists share the same binding behavior, but querySelectorAll specifically captures a point-in-time copy.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
- #dom
- #javascript
- #web-apis
- #browser
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on dom — each one lists the topics its interview covers.
See open roles