JavaScript Reference Equality — What is the Output?

Why This Question Matters

If you've spent any time with JavaScript, you've probably hit a wall where the language does something that feels completely illogical. This specific snippet is a classic "gotcha" that trips up almost everyone starting out—and even some seasoned devs when they're tired.

At first glance, it looks like basic math. You have two arrays, they both contain [1, 2, 3], so they should be equal, right? But in JS, the answer is a resounding false for both checks.

This happens because of how JavaScript handles primitive values versus reference types. If you don't understand the difference, you'll end up with bugs in your state management or API responses that are nearly impossible to track down.

Understanding the Code

Let's look at the snippet again:

const a = [1, 2, 3]
const b = [1, 2, 3]
console.log(a == b)
console.log(a === b)

When you write const a = [1, 2, 3], JavaScript doesn't just store the numbers in a variable. It creates an object (remember, arrays are just a special type of object in JS) somewhere in the computer's memory. The variable a doesn't actually "hold" the array; it holds a reference (a pointer) to the memory address where that array lives.

When you create const b = [1, 2, 3], JavaScript does the exact same thing. It allocates a *new* piece of memory for a *new* array. Even though the contents are identical, they are stored in two different locations.

So, when you run a == b or a === b, JavaScript isn't looking inside the arrays to see if the numbers match. It's asking: *"Do these two variables point to the exact same spot in memory?"*

Since they point to different addresses, the answer is false.

Finding the Correct Answer

The correct answer is that both statements return false.

Here is why the different operators don't save you here:

1. a == b (Abstract Equality): This operator attempts type coercion if the types are different. But here, both are objects. When comparing two objects, == checks for reference equality. Since they are different instances, it's false.
2. a === b (Strict Equality): This checks both the type and the value. Again, since we are dealing with objects, "value" means the memory address. They are different addresses, so it's false.

If you wanted this to be true, you'd have to do something like this:

const a = [1, 2, 3];
const b = a; // b now points to the SAME memory address as a
console.log(a === b); // true

Common Mistakes Developers Make

The biggest mistake is assuming JavaScript compares arrays by "value." In languages like Python, comparing two lists with the same elements returns true. JS doesn't do that.

Another common trap is using == thinking it's "looser" and will somehow "see" that the contents are the same. It won't. Whether you use double or triple equals, the result for two different array instances is always false.

Developers also often forget that this applies to objects too.
{ name: 'Dev' } === { name: 'Dev' } is also false.

Real-World Usage

This isn't just a trivia question; it breaks things in production every day. The most common place this bites you is in React or other UI frameworks that rely on "shallow comparison" to trigger re-renders.

Imagine you have a state variable that is an array. You update the data in that array but don't change the reference:

const [items, setItems] = useState([1, 2, 3]);
const updateItems = () => {

  items.push(4); 

  setItems(items); // This won't trigger a re-render!

};

React checks if the old items is the same as the new items using ===. Since you mutated the original array, the reference is still the same. React thinks nothing changed and your UI stays frozen. This is why we use the spread operator [...items, 4] to create a *new* array reference.

To actually compare if two arrays have the same values, you have to manually check them. For simple arrays, JSON.stringify(a) === JSON.stringify(b) is a quick-and-dirty hack, but for professional work, you'd use a loop or a utility like Lodash's _.isEqual().

Key Takeaways