Understanding text reversal
Backwards — at three different scales.
Reversing text is a small toy with a surprisingly subtle implementation, especially once Unicode shows up.
Three reversal granularities.
By character: the simplest. "abc" → "cba". By word: split on whitespace, reverse the array of words, join back. "the quick brown fox" → "fox brown quick the". By line: split on newlines, reverse the array, rejoin. All three are purely cosmetic — the source data is unchanged byte for byte after the operation, just rearranged.
The Unicode trap.
A naive character-reversal in JavaScript splits on UTF-16 code units. That breaks for characters that take two units — many emoji (👍 = two code units), CJK extended characters, and combining-mark sequences (é stored as e + ́). The tool uses code-point-aware splitting to keep emoji and accented characters intact. A flag emoji is still two code points after reversal but it's the right two; combining marks stay attached to their base letter.
Right-to-left scripts.
Arabic and Hebrew are stored left-to-right in memory but rendered right-to-left on screen. Reversing them looks fine in the browser (because the bidi algorithm puts them in display order anyway) but produces nonsense if you paste the result into something that doesn't run bidi. For RTL text, "reverse" rarely means what you want — the script already reads in the direction you'd be flipping it to.
Why anyone reverses text.
Spotting palindromes ("racecar" reads the same backwards), generating obfuscated handles, fixing accidentally-reversed imports from a tool that wrote things in the wrong direction, building word puzzles, and a small amount of coded humour. The function is rarely the answer to a real engineering problem — when it is, you usually want it as part of a longer transformation.