Understanding Objects in JavaScript

If you’ve been using JavaScript for more than five minutes, you’ve probably heard the phrase: "Almost everything in JavaScript is an object." But what does that actually mean?

Whether you’re storing a user’s profile or building a complex game, objects are the backbone of how we organize data. Let's break down how they work, why we use them, and the "secret" relationship they share with arrays.

What are Objects and Why Do We Need Them?

Think of an Array as a simple shopping list—it’s great for a collection of similar items where order matters. But what if you want to describe a specific person? An array like ['Rachit', 18, 'IIT Dholakpur'] is confusing. Is 28 her age or her house number?

An Object solves this by using key-value pairs. It allows us to label our data, making our code readable and organized.

Creating and Managing Objects

// Creating an object
const person = {
  name: "Rachit",
  age: 18,
  college: "IIT Dholakpur",
  branch: "Kabutar science"
};

1. Accessing Properties

There are two main ways to get data out of an object:

• Dot Notation: person.name (Simple and most common).

• Bracket Notation: person["age"] (Useful when the key name is stored in a variable).

2. Updating, Adding, and Deleting

Objects are flexible. You can change them on the fly:

person.age = 19;              // Updating
person.job = "Developer";     // Adding
delete person.branch;           // Deleting

Looping Through Objects

Because objects are not strictly ordered like arrays, you can't use a standard for loop with a number counter. Instead, you have a few specialized options.

1. The for...in Loop
   This loop iterates directly over the keys of an object.

   const book = { title: "1984", author: "George Orwell", pages: 328 };
   
   for (let key in book) {
     console.log(`The \({key} is \){book[key]}`);
   }
   // Output:
   // The title is 1984
   // The author is George Orwell
   // The pages is 328
   

2. Modern Object Methods (Often Preferred)
   JavaScript provides built-in methods that convert parts of an object into an array, which you can then loop over using array methods like .forEach()

• Object.keys(obj): Returns an array of the keys ["title", "author", "pages"]

• Object.values(obj): Returns an array of the values ["1984", "George Orwell", 328]

• Object.entries(obj): Returns an array of key-value arrays [["title", "1984"], ["author", "George Orwell"]]

// Example using Object.keys:
Object.keys(book).forEach(key => {
  console.log(key, book[key]);
});

The Big Reveal: Arrays are Secretly Objects

Here is where things get interesting. In JavaScript, arrays are actually specialized objects.

When you create an array ['A', 'B'], JavaScript essentially treats it like an object where the "keys" are the index numbers:

// What you write:
const letters = ['A', 'B'];

// How JS sees it (conceptually):
{
  "0": "A",
  "1": "B",
  length: 2
}

The main difference? Arrays come with built-in "superpowers" (methods) like .push(), .pop(), and the length property, which are designed specifically for ordered lists.

Going Deeper: The "Reference" Mystery

To truly master JavaScript, you have to look under the hood at how the computer stores your data. This is the "Aha!" moment where many bugs suddenly start to make sense.

In JavaScript, data is split into two categories: Primitives and Reference Types (Objects). They live in different parts of your computer's memory.

1. Primitives: The "Value" Storage

When you create a primitive (like a String, Number, or Boolean), JavaScript uses Stack Memory. The variable name is directly linked to the value.

let score = 10;
let newScore = score; // A real copy is made
newScore = 20;

console.log(score); // 10 (The original stays the same)

Think of this like photocopied paper. If you scribble on the copy, the original remains clean.

2. Objects: The "Pointer" Storage

Objects (including Arrays and Functions) are stored in Heap Memory. Because objects can grow very large, JavaScript doesn't store the actual object data inside the variable. Instead, the variable stores a Reference (a memory address or a "pointer") that tells the computer where to find the object in the Heap.

3. The "Remote Control" Effect

This is where developers often get tripped up. When you "copy" an object, you aren't copying the data—you are copying the address.

const user1 = { name: "Alice" };
const user2 = user1; // You just copied the "remote control," not the TV!

user2.name = "Bob";

console.log(user1.name); // "Bob" (Wait, what?!)

Because both user1 and user2 hold the same memory address, changing one affects the other. They are both pointing to the same spot in the Heap.

Why Arrays Are Also Objects (The "Hidden" Proof)

Earlier, we mentioned that arrays are just objects under the hood. We can prove this using the memory logic we just learned.

Since arrays are objects, they are also Reference Types. If you pass an array into a function and modify it, the original array outside the function changes too.

Furthermore, you can even add "string keys" to an array just like a standard object:

const myArray = [1, 2, 3];
myArray.description = "This is a secret property";

console.log(myArray.description); // "This is a secret property"
console.log(typeof myArray);      // "object"

While we use [] for arrays and {} for objects to keep our code clean, JavaScript sees them both as expandable containers stored in the Heap, waiting to be referenced.

Now that you know about references, try this:

1. Create a student object.

2. Create a new variable graduatedStudent and set it equal to your student.

3. Change a property on graduatedStudent.

4. Log the original student object. Does it show the change? (Hint: It should!)

To make the "Reference" mystery stick, let's look at why your assignment results might have surprised you. When you set graduatedStudent = student, you didn't actually create a second student; you just gave the same student a second name.

Breaking Down Your Assignment Results:

When you ran that code, here is what happened in your computer's memory:

1. The Original Object: You created student. JavaScript put that data in the Heap and gave the variable student a "pointer" (the address) to find it.

2. The Reference Copy: When you wrote graduatedStudent = student, you didn't copy the name or age. You copied that pointer.

3. The Mutation: When you changed a property on graduatedStudent, you were using that pointer to go to the Heap and change the original data.

4. The Result: When you logged the original student, it showed the change because both variables were looking at the exact same "box" in memory.

How Shallow and Deep Copies Change the Assignment

If you wanted to change the student's status without affecting the original record, you would need to "break the link" using the techniques we just discussed.

1. Using a Shallow Copy

If your student object is simple (no nested objects like a grades object), a Shallow Copy works perfectly:

// Instead of graduatedStudent = student;
const graduatedStudent = { ...student }; 

graduatedStudent.isGraduated = true;

console.log(student.isGraduated); // false (The original is safe!)

2. Using a Deep Copy

If your student object is complex—for example, if it has a metadata object inside it—a shallow copy fails the test. This is where structuredClone saves your data:

const student = {
  name: "Rachit",
  info: { year: 2026 }
};

// A shallow copy would still link the 'info' object
const graduatedStudent = structuredClone(student);

graduatedStudent.info.year = 2027;

console.log(student.info.year); // 2026 (The nested object is also safe!)

Conclusion: Why Does This Matter?

Understanding that objects are reference types isn't just "extra credit" knowledge—it’s the key to avoiding the most common bugs in JavaScript. When you update a user’s profile, modify a shopping cart, or pass data between components in a framework like React, knowing whether you are mutating the original data or creating a copy is the difference between a stable app and a broken one.

Next time you see an unexpected change in your data, ask yourself: "Am I holding the actual value, or just a remote control?"