Strings and Symbols

## What "immutable" means here A JavaScript string is a primitive value, like a number or a boolean. The character sequence it holds is fixed the moment the value exists, and nothing in the language can change it afterwards. Anything that looks like an edit — uppercasing, trimming, replacing, slicing — actually produces a *different* string value and leaves the original exactly as it was. This is a property of the *value*, not of the *variable*. `let s = 'hello'; s = 'world';` is perfectly legal: you rebound the name `s` to a different string. What you cannot do is turn the string `'hello'` itself into `'Hello'`. ## Why `s[0] = 'H'` does nothing Two separate mechanisms conspire here. First, indexed properties of a string are read-only. In spec terms a String exotic object exposes each index as a property with `writable: false`, `enumerable: true`, `configurable: false`. You can observe this directly: ```javascript console.log(Object.getOwnPropertyDescriptor(Object('hi'), '0')); // { value: 'h', writable: false, enumerable: true, configurable: false } ``` Second, `s` in the example is a *primitive*, not an object, and primitives have no properties of their own. When you write `s[0] = 'H'`, the engine temporarily wraps the primitive in a `String` object, attempts the assignment on that wrapper, and then throws the wrapper away. Even if the property were writable, the mutation would land on an object that is discarded on the next line. The outcome depends on the mode: ```javascript let s = 'hello'; s[0] = 'H'; console.log(s); // "hello" — the write was silently discarded function strictWrite() { 'use strict'; const t = 'hello'; t[0] = 'H'; // TypeError: Cannot assign to read only property '0' } ``` Sloppy mode ignores a failed assignment to a non-writable property; strict mode throws a `TypeError`. Since ES module code and class bodies are strict by default, in a modern codebase this usually throws rather than fails quietly — which is the friendlier outcome. ## Methods return new strings No method on `String.prototype` mutates its receiver. Every one of them is a producer: ```javascript const raw = ' Ada '; raw.trim(); // returns "Ada" — and the result is thrown away console.log(raw); // " Ada " — unchanged const clean = raw.trim(); // keep the result console.log(clean); // "Ada" ``` The forgotten-result bug is by far the most common way this bites people, and it is easy to miss in review because the line reads like it does something. A lint rule against unused expressions catches most instances. Contrast this with arrays, where some methods mutate (`push`, `sort`, `reverse`) and some copy. Strings have no such split: there is nothing to mutate. ## Reassignment is not mutation ```javascript let name = 'ada'; name = name.toUpperCase(); // rebinding the variable console.log(name); // "ADA" const fixed = 'ada'; // fixed = fixed.toUpperCase(); // TypeError: Assignment to constant variable ``` `const` prevents rebinding the *name*. It is not what makes the string immutable — the string was already immutable, and `let` does not make it any less so. Similarly, `Object.freeze('abc')` is pointless: since ES2015 it simply returns the primitive unchanged, because there was never anything mutable to freeze. ## Why this design is convenient Because a string can never change underneath you, passing one to a function is inherently safe: the callee cannot corrupt the caller's value, and you never need a defensive copy. The same property makes strings dependable keys in a `Map` or in a cache, and lets engines share and intern string data behind the scenes. The one cost people worry about is building a long string incrementally. The spec says each `+=` produces a new value, which sounds like quadratic work, but real engines represent concatenations with internal shared structures and flatten them lazily, so ordinary loop concatenation is usually fine. That is an engine optimisation, not a language guarantee — if it matters for your workload, measure it rather than repeating folklore. ## What an interviewer is really checking They want to see that you distinguish *value* from *variable*, that you know method calls are producers, and that you can name the strict-vs-sloppy difference rather than saying vaguely "it doesn't work".