Since ES2019, Array.prototype.sort is required to be stable. What exactly does that guarantee, and what can you build on it?

## What stability means here A sort is **stable** when elements the comparator declares equivalent — it returns `0` for that pair — come out in the same relative order they went in. It says nothing about elements the comparator can actually distinguish; those are ordered by the comparator, stable or not. ```js const rows = [ { name: 'Ada', score: 5 }, { name: 'Bo', score: 5 }, { name: 'Cy', score: 9 }, ]; rows.sort((a, b) => a.score - b.score); // Ada is guaranteed to still precede Bo: the comparator returns 0 for them. ``` ## The ES2019 change Before ES2019, the specification explicitly left the ordering of equal-comparing elements unspecified. Engines exploited that: it was common to use a simple insertion-style approach for short arrays, which is naturally stable, and switch to a faster but unstable strategy above a threshold. The observable result was a genuinely nasty class of bug — the same code preserved tie order for a list of eight rows and scrambled it for a list of eighty, so it looked fine in development and broke on real data. ES2019 removed that freedom for `Array.prototype.sort`: stability is now required, and current engines comply. If you support environments predating that edition, you cannot rely on it and must add an explicit tiebreak instead. ## What it buys you **Sequential sorting.** Sort by the least significant key first and the most significant key last; each later pass preserves the ordering established by the earlier ones within its tie groups. ```js const view = [...rows] .sort((a, b) => a.name.localeCompare(b.name)) // secondary .sort((a, b) => b.score - a.score); // primary // highest score first; equal scores stay alphabetical ``` This is the natural model for an interactive table: the user clicks "Name", then clicks "Score", and expects rows with the same score to remain alphabetical. Implementing that with a single comparator would require the UI to remember and re-express every previous click as a chained term; leaning on stability, each click is one more `sort` call. **Reproducibility.** With a consistent comparator and a stable sort, the same input array always yields the same output array — no engine-dependent shuffling of ties. That matters for snapshot tests, for rendering lists with keys, and for any diff between two runs. **Cheap partial ordering.** You can group or partition first and refine later without worrying that the refinement destroys the earlier arrangement. ## What it does not buy you - **It does not make an invalid comparator safe.** If the comparator is not consistent — a boolean return, a `NaN`, a random value, a non-transitive rule — the resulting order is implementation-defined. Stability is a promise about ties under a *valid* comparison; it is not a promise about garbage in. - **It says nothing about ordering across different inputs.** Two arrays containing equal elements in different original orders will sort to different outputs. If you need a canonical order regardless of input order, add a final tiebreak on a unique key, such as an id. - **It is not a statement about performance or algorithm.** The spec constrains observable ordering, not the strategy an engine picks. ## The explicit alternative When you want an ordering that does not depend on stability at all, make the comparator a total order by appending a unique tiebreak: ```js const cmp = (a, b) => b.score - a.score || a.id - b.id; ``` Now no two distinct elements ever compare equal, so stability is irrelevant and the result is identical on every engine, in every edition, for any input permutation. This is the defensive choice for data that crosses a wire or lands in a snapshot test. ## How to answer this in an interview Define stability precisely (ties keep input order), date the guarantee (ES2019) and say what preceded it (unspecified, and observably unstable above engine thresholds), give the one killer use case (sequential multi-key sorting for clickable table headers), and then show judgment by noting the limit — it does not repair an inconsistent comparator, and a unique-key tiebreak is stronger when you need a canonical order.