Strings

One smile, three answers

Type "😀" into a Twitter compose box and the counter goes up by one. Type the same character into a JavaScript console and '😀'.length is 2. Send it to a Postgres column and four bytes hit the disk. None of these is wrong. They're answering different questions about the same string — and the gap between those answers is where every painful string bug lives.

Code units, not characters

A string isn't a row of "letters." It's a row of integers, and an encoding rule decides what those integers mean. JavaScript and Java pick UTF-16: each integer is 16 bits wide, called a code unit. The string "hi" is the row [0x0068, 0x0069] — two code units, two boxes, same shape as the array from the previous lesson.

function get(s, i) {
  // 16-bit code unit at offset i × 2 bytes.
  return s.charAt(i);
}

For ASCII text — "hi", "router-config-v3", anything you'd type without holding the option key — one code unit equals one visible character, and the array model carries over cleanly. s.length is the count, s[i] is the character, life is simple.

The visualiser above shows that simple case first: a UTF-16 row for "hi", with each cell holding a hex code unit and a rendered text strip below it that interprets the integers. Read s[0]. Same shape as arr[0]. Then watch what happens when the smile lands.

What "modify" really means

Strings are immutable. Unlike the array from the previous lesson, s[2] = 'x' is not a thing — there is no in-place write. That's why every row in the visualiser shows up with a lock icon the moment it's committed. Concatenation, slicing, replacement — all of them allocate a new row and copy.

function concat(a, b) {
  // Strings are immutable: a and b are unchanged.
  return a + b; // allocates a new row
}

Watch what happens when the visualiser evaluates "hi" + "!". The original "hi" row stays exactly where it was — locked, unchanged, still readable from any other reference. A new row is allocated below, three cells wide, with the integers from "hi" and "!" copied in. Nothing was edited. Something new was built.

This is the part that turns innocent-looking code into performance traps. If concatenation always copies, then concatenation in a loop copies the same prefix over and over.

The Schlemiel-the-Painter trap

Here is the canonical bad version. It looks fine. It works. It will also melt your laptop on a long input.

let result = "";
for (let i = 0; i < parts.length; i++) {
  result = result + parts[i]; // each += allocates
}

Each iteration takes the current result, allocates a new row one cell longer, and copies everything that was already there plus the new piece. After 4 iterations, the total work isn't 4 — it's 1 + 2 + 3 + 4 = 10. After n iterations, it's n(n+1)/2. Quadratic.

The fix is the same one Java's StringBuilder and Go's strings.Builder were invented for: collect into a buffer, allocate once at the end.

const buf = [];
for (let i = 0; i < parts.length; i++) {
  buf.push(parts[i]); // O(1) push
}
const result = buf.join(""); // single allocation

Same answer, linear cost. The visualiser shows both side-by-side: red counter for the quadratic version that visibly accelerates, green counter for the linear version that ticks once at the end. The shapes don't lie.

V8 and other modern engines do soften the quadratic case via internal "rope" structures that defer the copy until the string is actually read. Don't rely on this. The optimisation is fragile; the moment something logs the partial result or compares it, the rope flattens and you pay the bill.

When length stops meaning "characters"

Now the smile. Append "😀" to "hi!" and the new row is five cells wide, not four. The smile is a code point above U+FFFF — outside what 16 bits can represent — so UTF-16 stores it as a surrogate pair: two code units that, taken together, encode one character. The visualiser draws a thin bracket above those two cells with a 1 code point label, but s.length doesn't see the bracket. It just counts cells.

If you got that one off, you're in the same place as every team that has ever shipped a "280-character tweet" feature. JavaScript's length answers a question — how many UTF-16 code units? — that almost never matches the question your product wants answered, which is how many characters does a human see?. Twitter computes its own count. So does every input-validation library worth using.

Indexing returns half a smile

Here's the real trap. If you index into a surrogate pair, you don't get the character. You get half of it.

The cell at index 3 holds 0xD83D — a high surrogate. On its own, it isn't a valid Unicode character. Renderers display it as �, JSON encoders complain about lone surrogates, regex engines refuse to match it. The lesson isn't "indexing is broken." The lesson is that s[i] answers a question about code units, not a question about characters. To iterate by character, use for..of or spread [...s] — those yield code points, not code units.

The same trap shows up when slicing.

slice(0, length / 2) is character-safe for ASCII strings and mostly safe for European text (which fits in BMP code points), but it can bisect a surrogate pair on any input that has emoji, mathematical symbols, or non-BMP CJK extensions. In a search-suggestions feature, that's a � showing up in the dropdown. In a logs pipeline, it's a downstream parser crashing on an invalid UTF-8 sequence after a re-encode.

Where the trade-offs sit

A raw string is brilliant when the workload is:

• A few values to read or compare.
• Concatenations done once, not in a loop.
• Text where one code unit equals one character (ASCII, most European text in NFC form).

It's the wrong primitive when:

• You're building output incrementally in a loop. Use an array buffer and .join(""), or stream directly to wherever the bytes need to go.
• You need to count characters as a human sees them. Use a grapheme-cluster library; do not trust length.
• You're slicing arbitrary user-supplied text. Either iterate by code point, or accept that you might cut a surrogate pair and add a normalisation step.
• You need locale-aware comparison or case folding. === and toLowerCase() are not what you want; pass an explicit locale to localeCompare and toLowerCase, and never use case-insensitive equality for security checks.

Where this shows up in real systems

A few places the integer-array view of strings turns from interesting to load-bearing:

• JSON parsers: parsing performance is dominated by string handling — finding quote boundaries, validating UTF-8, unescaping. simdjson hits gigabytes per second by treating JSON's strings as raw byte arrays and using SIMD to scan them. Source: simdjson.org.
• V8 string representation: V8 internally has at least four different string layouts — SeqOneByteString (Latin-1 packed, half the memory), SeqTwoByteString (UTF-16), ConsString (concatenation tree, lazy), and SlicedString (a view into a parent string). Calling console.log(s) on a deeply concatenated string sometimes triggers a "flatten" that walks the cons tree and allocates a fresh contiguous buffer.
• Java compact strings (JEP 254): since JDK 9, Java stores strings as byte[] plus a 1-byte coder field. Pure Latin-1 strings take half the memory of pre-9 UTF-16 strings. Most real Java apps got a measurable heap reduction the day they upgraded.
• Postgres TEXT / VARCHAR: stored inline up to ~2 KB, then transparently TOASTed (compressed and moved out-of-line) for larger values. The encoding is a database-level setting; mismatched encodings between client and server are the classic cause of ? corruption that survives every "fix" except actually agreeing on UTF-8.
• DNS labels: each label in a domain name is at most 63 bytes, total wire-form name at most 255. Non-ASCII domains go through Punycode — münchen.de becomes xn--mnchen-3ya.de on the wire. The whole protocol assumes a fixed, byte-counted encoding.

The three answers from the start — Twitter says one, JavaScript says two, Postgres says four — were each correct under their own encoding rule. Once you see strings as integer arrays with a rule on top, the disagreement stops feeling mysterious and starts feeling like exactly what it is: three different rules, three different counts, no single right answer.

What to learn next

• Hash maps — when you need O(1) lookup by a string key, and the string's hashCode() becomes the operation that matters.
• Two pointers — the first pattern that exploits left-to-right traversal of a string for problem solving.
• KMP and Rabin-Karp — substring search that beats the naïve O(n × m) we glossed past.