A Visual Guide to References in JavaScript

Let’s rewind to before objects entered the picture, back when copying felt honest. Here’s a score that isn’t inside an object — run the three lines and keep an eye out for wires:

Did you spot the difference? The value sits right on the tag — no wire, no shared anything. Copying the tag copies the value, and after line 3, score holds a new 10 while savedScore calmly keeps its own 7. This is the happy world we all assumed we lived in.

There’s a deeper reason numbers behave, and it matters for everything ahead: you can replace a number, but you can’t open up the number 7 and edit a piece inside it. It has no inside.

Now that we can see wires, I can show you the distinction that took me months to notice. These two lines differ by six characters, and I honestly used to think they did the same thing. Run them and watch the wire:

Line 1 never touched the wire. It walked down it, opened the object at the far end, and edited the score sitting inside. That inside-edit has a name you’ll hear constantly: mutation — and because it happens to the object itself, every name wired to that object sees it. That’s exactly what stung us in the opening bug.

Line 2 is a replacement. It unhooked the wire and attached it to a brand-new object. Notice the old object in the board: nothing about it changed. It’s just no longer where this particular wire points.

Time to test the theory. Same setup as my bug, one small twist — and I want you to commit to an answer before you peek, because the guess is what makes the lesson stick.

Now you’ve earned the official word for all of this. That invisible wire — the way a variable reaches one particular object — is what developers call a reference. When someone says “those two variables reference the same object,” they mean precisely what you just watched: two names, one object. (There are no literal wires inside your computer, of course — a reference is closer to an address the engine follows — but the wire picture predicts everything JavaScript will do with objects, and that’s all we need from it.)

So what would it actually take to free the two names from each other? Here’s the part that surprised me: nothing you do to the values inside helps. Run this one line and watch:

Here’s an innocent-looking helper. It doesn’t return anything. It just “renames a player.” Make your prediction before you tap an answer.

This one bothered me for a long time, so let’s watch it under the X-ray. The function didn’t reach backward into my variable — nothing that dramatic happened. Step through the call:

That’s the whole story: calling rename(player) copied the wire — exactly like backup = player did — and hung it on a temporary tag called currentPlayer. Two names, one object; one of the names just happens to live inside a function. And when the function returned, the tag vanished but the edit stayed, because the edit was never on the tag. It was in the object.

Ever since this clicked, I ask one question about every helper I hand an object to: does this function return a new value, or does it edit the one I gave it? That single question has saved me hours of debugging, and by the end of this page you’ll see it catch a real bug.

The fix turned out to be simple, once I understood the problem. I didn’t need a smarter = — I needed to explicitly ask JavaScript to build a second object. The spread syntax does exactly that. Run it and look for the moment a second box appears:

{ ...player } means “create a brand-new object, then copy player’s top-level properties into it.” For the first time in this whole story, player and checkpoint lead to different objects — and when line 2 changed one score, the other genuinely didn’t care. This is the backup I thought I was making on that painful afternoon.

Feeling confident with my new spread trick, I copied a player whose stats lived in a nested object. You already know something’s coming — but predict exactly what:

To see why, we need the X-ray one more time — because the wire that betrayed us is hiding inside the copy. Watch the stats property as the two lines run:

There it is: a new outer shell whose stats property is — you guessed it — a copied wire, running straight to the same inner object as before. Developers call this a shallow copy, and it’s not a flaw; it’s the same rule from line 2 of our story, applied one level down.

The defense is honest work: copy every level along the path you plan to change.

const checkpoint = {
  ...player,
  stats: {
    ...player.stats,
    name: "Lin"
  }
};

The first time I compared two identical-looking objects, the answer felt like another betrayal. Two objects, byte-for-byte the same data — and === says false. Trace it yourself:

Watch what === actually did: it never opened the boxes to read their contents. It checked one thing — do these two wires end at the same object? Identical data, different objects: false. Then b = a swung the wire, and the very same comparison became true, even though no data changed anywhere.

That “which exact object is this?” quality has a name — identity — and it’s the last piece of the model. Equality of objects in JavaScript is about the wires, never the contents.

This is a real bug I’ve both written and approved in code review. It ships all the time, because every line of it looks correct:

function lowestScore(scores) {
  scores.sort((a, b) => a - b);
  return scores[0];
}

const leaderboard = [30, 10, 20];
const lowest = lowestScore(leaderboard);

lowest comes back as 10, which is exactly right. And yet somewhere else in the app, the leaderboard now displays [10, 20, 30] — reordered by a function that was only supposed to read it. You already have everything you need to narrate this crime. Watch it happen:

Arrays are objects, so the parameter scores is a wire to the caller’s array — and sort() mutates the object at the end of the wire. Remember the question from the rename section: “does this function edit the value I gave it?” Here it pays off. The fix is to sort a copy:

function lowestScore(scores) {
  return [...scores].sort((a, b) => a - b)[0];
}

Now the copy gets rearranged, the original order survives, and nobody debugs a leaderboard that sorts itself.