As far as I can tell, reading the spec, you're totally wrong. Specifically, I believe that it is not true that every time the computer compares two strings tha

As far as I can tell, reading the spec, you're totally wrong. Specifically, I believe that it is not true that every time the computer compares two strings that it needs to compare length. Whether or not any string or strings is/are "interned" is completely implementation-dependant. To elaborate, you could make a compliant EcmaScript interpreter wherein ALL strings, as they are constructed, are compared (presumably by hashing) against a global list of all already-constructed strings, and if the new string already existed, the in-memory representation of the string is a reference to the One True Instance of that string, such that equality comparison can always done by reference equality. Every string construction is slow, and every string comparison is constant time. Would this be smart, no. But it is consistent with the semantics that the ES spec puts on strings, which is that they are not arrays, they are primitive immutable sequences of codepoints. You could also, as you perhaps are suggesting in your first parenthetical aside, implement a compliant ES interpreter where the characters of a string are not stored in contiguous memory, being perhaps stored in some kind of complicated tree or linked lits or something. I cannot see any upside to that one. Well, I guess on very particular types of data you could save a lot of space, but wow that would be atypical. More broadly, and more of a subjective opinion, I think you're completely making the case of the top-level commenter. If someone comes into a language assuming that they know which values are values and which are references, they're going to make a lot of errors. They're going to misunderstand what equality checking does, they're going to unnecessarily make defensive copies of immutable values to avoid aliasing problems, they're going to try to mutate things, etc.