What is the difference between Array.prototype.includes and Array.prototype.indexOf, and why can indexOf never find NaN inside an array?

## Two questions, two return shapes `Array.prototype.indexOf(searchElement, fromIndex)` returns the index of the first element equal to `searchElement`, or `-1` if there is none. `Array.prototype.includes(searchElement, fromIndex)` returns a boolean. `includes` arrived in ES2016 largely because the older idiom `arr.indexOf(x) !== -1` is easy to write wrong — `-1` is truthy, so a bare `if (arr.indexOf(x))` is broken for both the miss case and a match at index `0`. Neither takes a predicate. Both compare a **value** you hand them, which is what separates them from `find` and `some`. ## The comparison algorithm is the real difference `indexOf` compares with the spec operation `IsStrictlyEqual` — exactly what `===` does. `includes` compares with **SameValueZero**. The two rules agree on everything except one value: - `NaN` is not strictly equal to anything, including itself. IEEE-754 defines it that way because `NaN` means "not a number", and no two unknowns are known to be equal. So `indexOf` can never match a `NaN` element. - SameValueZero is defined as "same value, but `+0` and `-0` count as the same". It reports `NaN` equal to `NaN`, so `includes` finds it. ```js const xs = [1, NaN, 3]; xs.indexOf(NaN); // -1 — strict equality, NaN === NaN is false xs.includes(NaN); // true — SameValueZero treats NaN as equal to itself ``` A common wrong answer is that `includes` also differs on `-0`. It does not: strict equality already reports `+0 === -0` as `true`, and SameValueZero deliberately keeps that behaviour (that is the "Zero" in the name). So `[0].includes(-0)` and `[-0].indexOf(0)` both report a match. If you need `+0` and `-0` to be distinguishable, neither of these methods will do it. Because `NaN` is the only divergence, the practical rule is: any array whose values can be the result of arithmetic — a parse, a division, a subtraction that hit a missing field — can contain `NaN`, and a membership check written with `indexOf` will silently claim it is absent. ## Sparse arrays: holes A *hole* is an index that was never assigned — produced by `Array(3)`, by `[1, , 3]`, or by raising `length`. Holes are not the value `undefined`; the index simply does not exist on the object. `indexOf` checks for the property's presence and skips holes entirely. `includes` reads every index from `fromIndex` to `length - 1` and a missing index reads as `undefined`. Hence: ```js const sparse = Array(3); // three holes, length 3 sparse.indexOf(undefined); // -1 — holes skipped sparse.includes(undefined); // true — holes read as undefined ``` This is the second divergence, and it is worth naming in an interview because it shows you know holes are a distinct state rather than a synonym for `undefined`. ## fromIndex behaves the same way Both accept an optional second argument. A negative `fromIndex` is added to `length`; if the result is still negative, the whole array is searched. `arr.includes(x, -2)` therefore checks only the last two elements. `indexOf` has an extra sibling, `lastIndexOf`, which scans backwards; `includes` has no such variant because direction cannot change a boolean. ## What neither of them does Both compare values, so for objects they compare **references**. Two structurally identical objects are different values, and `includes` reports `false`. To search by content you need a predicate — `some` for a boolean, `find` or `findIndex` for the element or its position. ```js [{ id: 7 }].includes({ id: 7 }); // false — different references [{ id: 7 }].some(o => o.id === 7); // true — content comparison ``` A subtler point about strings: these methods compare whole elements, not substrings. `['abcd'].includes('bc')` is `false`. `String.prototype.includes` is a different method that *does* do substring search, and confusing the two is a common slip. ## Choosing between them Use `includes` whenever the question is membership: it reads as the intent, returns a boolean you can use directly, has no `-1` trap, and handles `NaN`. Reach for `indexOf` only when the position is what you need next. If the array is large and the membership check runs repeatedly, both are linear scans, and the usual fix is to build a keyed lookup once instead of rescanning — but for a one-off check on a small array, `includes` is the clear default.