Why Are Strings Immutable?

Because strings are values, and values are not supposed to change behind your back. If a string could be edited in place, then two variables holding the same string could end up with different contents, and you would have no way to know which one you were reading. Making strings immutable means the value you have is the value you will always have.

const original = "hello";
const changed = original.toUpperCase();

console.log(original);   // "hello"
console.log(changed);    // "HELLO"

// Assigning to an index does nothing.
original[0] = "H";
console.log(original);   // "hello"

// Strings are compared by value.
console.log("a" + "b" === "ab");   // true

That safety is what lets the engine optimise aggressively. Because a string can never change, the engine can share one copy between every variable that holds the same value, cache the result of a property lookup keyed by that string, and use the string as a key in a map without worrying about the key being modified behind it. Hashing a string for a map lookup would be much more expensive if the string could change while it was in the map.

Immutability also removes a whole class of bugs in concurrent code. If two parts of a program share a string, neither can change what the other one sees. There is no need to copy before handing a string to a function, because the function cannot change it.

The cost is that every change allocates. Building a long string by repeated concatenation creates a new string each time, and the earlier ones become garbage. That is the performance reason to collect pieces in an array and join once, rather than concatenating in a loop.

It cuts both ways. Because a string can never change, the engine can store one copy and share it between every variable that holds the same value. Interning, which is the automatic sharing of identical string literals, means the engine can spot two equal literals at compile time and point both at the same memory. That is why comparing two equal strings is cheap.

const a = "hello";
const b = "hello";
console.log(a === b);   // true - the same primitive value

// Repeated concatenation allocates a new string every time.
let out = "";
for (let i = 0; i < 1000; i++) {
  out += "ab";
}
console.log(out.length);   // 2000

// Collecting the pieces and joining once is usually faster.
const pieces = [];
for (let i = 0; i < 1000; i++) {
  pieces.push("ab");
}
console.log(pieces.join("").length);   // 2000

The cost of immutability is allocation. Every modification produces a new string, and the old one becomes garbage for the collector to reclaim. Repeated concatenation in a loop is the classic example, and because each step copies the whole accumulated string, the total work grows with the square of the length.

Modern engines partly hide this with a rope representation, where a long string is stored as a tree of smaller pieces and only flattened when something needs the characters one at a time. That makes concatenation much cheaper than it used to be, but it does not remove the allocation, and the flattening cost still has to be paid eventually.

The practical advice is simple. For a handful of concatenations, do not worry about it. For building a large string in a loop, push the pieces into an array and join once. And if you are appending to a string repeatedly, a list is the right data structure rather than a string.

Nothing useful happens. Strings are primitives and immutable, so there is no in-place modification to perform.

let text = "hello";

text[0] = "H";
console.log(text);   // "hello" - unchanged

// To change it, build a new string.
const upper = text.toUpperCase();
console.log(upper);   // "HELLO"
console.log(text);    // "hello" - the original is still there

// Or replace a substring.
console.log(text.replace("hello", "goodbye"));   // "goodbye"

// Note the difference between mutating and reassigning.
text = text.toUpperCase();
console.log(text);   // "HELLO" - the variable now points at a new string

Assigning to a string index does nothing at all in sloppy mode, and in strict mode it throws a TypeError. Since every ES module is strict, module code gets the error, which is the friendlier outcome because it makes the mistake obvious rather than leaving you wondering why the string did not change.

The last two lines of the example are the distinction worth being precise about. Calling toUpperCase and throwing the result away changes nothing, because the original string still exists and is unchanged. Reassigning the variable to the result of toUpperCase is what actually changes what the variable points at. The string value itself never changed; the binding moved to a different string.

That is why the advice is to write text = text.toUpperCase() rather than text.toUpperCase() on its own. The first form makes the intent obvious, and it is the only form that does anything.