In JavaScript, why does ['zebra', 'Apple', 'ähre'].sort() produce ['Apple', 'zebra', 'ähre'], and how do you get human-expected alphabetical order?

## What the default actually compares When `sort` gets no comparator, each element is converted to a string and the strings are compared with the same rules the `<` operator uses. That comparison is purely mechanical: walk both strings, and at the first position where the code units differ, the smaller code unit wins. If one string runs out first, it is the smaller one. ```js console.log('A' < 'a'); // true — 0x41 < 0x61 console.log('Z' < 'a'); // true — 0x5A < 0x61 console.log('z' < 'ä'); // true — 0x7A < 0xE4 ``` So the result `['Apple', 'zebra', 'ähre']` follows directly: capital `A` first because uppercase ASCII occupies 0x41–0x5A, then lowercase ASCII 0x61–0x7A, then everything above ASCII. Two consequences bite in real applications: - **Case segregation.** A name list sorts as `Álvarez`? no — plainly: `Adams, Baker, adams, baker`, with every capitalised entry above every lowercase entry, which no user expects. - **Non-ASCII exile.** Accented Latin letters, Greek, Cyrillic, and CJK all sort after the whole ASCII alphabet, in code-point order rather than in any language's alphabet. ## The fix: localeCompare `String.prototype.localeCompare(that)` compares two strings using locale-aware collation rules and returns a negative number, zero, or a positive number. That is precisely the comparator contract, so it plugs in directly: ```js const names = ['zebra', 'Apple', 'ähre']; names.sort((a, b) => a.localeCompare(b)); // ['ähre', 'Apple', 'zebra'] — ä collates with a, case is a minor difference ``` Collation is a linguistic operation, not a numeric one. It treats case and accents as *secondary* differences: `a` and `A` are the same letter that differ only in case, and `ä` is a variant of `a` in many locales, so both sort next to their base letter rather than far away from it. That is the behaviour users mean by "alphabetical". Two details worth stating: - **Only the sign is defined.** The specification does not fix the magnitude of `localeCompare`'s result, so never test `=== -1`; test `< 0`. - **Results are locale-dependent by design.** Different languages genuinely order letters differently, so the same array can legitimately sort differently under different locales. Pass the locale explicitly when the ordering must be predictable rather than dependent on the environment's default. ## Cheap alternatives, and when they are wrong A common shortcut is to normalise case first: ```js names.sort((a, b) => { const x = a.toLowerCase(), y = b.toLowerCase(); return x < y ? -1 : x > y ? 1 : 0; }); ``` This fixes case segregation and nothing else: `ähre` still sorts after `zebra`, because lowercasing does not change the code point of `ä`. It is acceptable only for data you know is ASCII — machine-generated identifiers, slugs, enum names. For anything a human typed, it is the wrong tool. Conversely, code-unit order is the *right* tool when you need a stable, locale-independent, machine ordering: sorting keys for a canonical serialisation, ordering hashes, or building a deterministic index. In those cases the whole point is that the result must not vary with the user's language settings. ## Cost Collation is much more expensive than a code-unit comparison, and the comparator runs on the order of n log n times. For long lists, hoist the collator instead of calling `localeCompare` on each pair: `Intl.Collator` exposes a `compare` method that is bound and reusable, and passing it directly as the comparator avoids re-resolving locale data per comparison. ```js const collator = new Intl.Collator('de'); names.sort(collator.compare); ``` ## Chaining Because `localeCompare` returns a signed number, it composes with other comparison terms exactly like a subtraction does — for instance as the primary term of a multi-key comparator, with a numeric term breaking its ties.