When the Built-In Sort Is Enough (and When It Isn't)

Every sorting lesson in a typical algorithms course spends real time on implementing quicksort, heapsort, and comparing their trade-offs by hand. This course spends one lesson on that (the divide-and-conquer lesson, via merge sort) and this lesson instead on the far more common real question: is Array.prototype.sort() good enough, and how do you know.

The complexity you're actually getting

const names = ["Priya", "Marcus", "Yuki", "Anish"];
names.sort(); // ["Anish", "Marcus", "Priya", "Yuki"]

Current JavaScript engines guarantee sort() runs in O(n log n) — V8 (Chrome, Edge, Node) has used a hybrid Timsort-based approach since 2018, replacing an older implementation that used O(n²) insertion sort for small arrays in some cases. This matters concretely: Array.prototype.sort is not a naive O(n²) algorithm you need to work around — it's already the same complexity class this course proved for merge sort, and O(n log n) is provably the best any comparison-based sort can achieve in the general case (a mathematical floor, not just "the best anyone's found yet").

The comparator bug that silently corrupts numeric data

The single most common real bug with sort():

[10, 1, 21, 2].sort();          // [1, 10, 2, 21] — WRONG for numbers
[10, 1, 21, 2].sort((a, b) => a - b); // [1, 2, 10, 21] — correct

Without a comparator, sort() converts every element to a string and compares lexicographically. "10" sorts before "2" as a string, because "1" (its first character) is lexicographically less than "2" — completely wrong for numeric intent, and it produces no error, no warning, just a silently wrong order that only shows up as a confusing bug report later. (a, b) => a - b (ascending) or (a, b) => b - a (descending) is the fix, and it's worth writing on every numeric sort out of habit, not just when a bug appears.

Stability, and why it matters for real UI sorting

const rows = [
  { name: "Priya", dept: "Design" },
  { name: "Anish", dept: "Eng" },
  { name: "Marcus", dept: "Design" },
  { name: "Yuki", dept: "Eng" },
];
 
rows.sort((a, b) => a.name.localeCompare(b.name));
// Anish, Marcus, Priya, Yuki
 
rows.sort((a, b) => a.dept.localeCompare(b.dept));
// Design: Priya, Marcus  <- still in NAME order within the tie
// Eng: Anish, Yuki       <- still in NAME order within the tie

Array.prototype.sort is specified as stable: elements the comparator considers equal keep their original relative order. This is exactly the behavior a "click a column header to sort, click another to re-sort" table UI depends on — a user who sorts by name, then by department, reasonably expects people within the same department to still read in name order, not get shuffled arbitrarily. Stability is what makes that expectation reliably true rather than a coincidence of implementation details.

When the built-in sort genuinely isn't the right tool

sort() is a general-purpose, comparison-based algorithm — it makes no assumptions about your data beyond "I can compare any two elements." That generality is exactly why it can't beat O(n log n): a comparison-based sort fundamentally cannot do better in the worst case, a real, provable result. Specialized alternatives only win by exploiting something sort() structurally can't use:

• Counting sort, when values are integers within a small, known range (say, exam scores from 0–100) — count occurrences of each value directly, producing an O(n + k) sort (k being the range size), genuinely beating the O(n log n) comparison floor because it never compares elements to each other at all.
• Maintaining a sorted structure incrementally, when data arrives one item at a time and you need "keep it sorted" continuously — re-running sort() on the whole collection after every single new arrival is wasteful compared to inserting the new item directly into its correct position (a binary-search-based insertion, covered next lesson, keeps each insertion to O(log n) to find the spot, though shifting elements in an array is still O(n) — the real win here is usually a different structure entirely, like the balanced-tree variants mentioned in the binary-trees lesson).

For the overwhelming majority of real frontend sorting — table columns, leaderboards, search result ranking — Array.prototype.sort() with a correct, explicit comparator is already the right tool, at the right complexity, with a real stability guarantee. Reach for something else only when you can name the specific extra structure in your data that a comparison-based sort can't exploit.

What to remember

• Array.prototype.sort() runs in O(n log n) in current engines — a real guarantee, not a naive fallback, and the same complexity class as merge sort.
• Sorting numbers without an explicit comparator silently uses string comparison, producing wrong results with no error — always pass (a, b) => a - b (or b - a) for numeric sorts.
• sort() is specified as stable — equal elements keep their original relative order — which is exactly what real multi-column table sorting depends on.
• Reaching for a specialized sort (counting sort, an incrementally maintained structure) is only justified when you can name a specific property of your data — a small known value range, or streaming arrival — that a general comparison-based sort structurally cannot exploit.