Why Objects Share Behavior: The Story of prototype and __proto__ in JavaScript

At some point, you create multiple objects…

and they all seem to “share” the same behavior.

You didn’t copy methods into each one.

You didn’t manually connect them.

Yet somehow, they all know what to do.

That’s not magic.

It’s the prototype system working behind the scenes.

Two Sides of the Same System

To understand this, you need to look at it from two perspectives.

On one side, there’s the function.

On the other, the object created from it.

JavaScript uses two different properties to connect these worlds:

• prototype
• __proto__

They are related.

But they play completely different roles.

The Function Side: prototype

Every function in JavaScript has a property called prototype.

function Person() {}

Person.prototype.sayHi = function () {
  console.log("Hi")
}

This prototype is just an object.

But it has a special purpose.

It acts as a shared storage for all instances created from that function.

Instead of copying sayHi into every object, JavaScript keeps it in one place.

The Object Side: __proto__

Now when you create an object:

const p = new Person()

JavaScript automatically links that object to the function’s prototype.

Internally, it does something like this:

p.__proto__ = Person.prototype

This is the connection.

The object doesn’t own the method.

It knows where to look for it.

How Property Lookup Actually Works

When you call:

p.sayHi()

JavaScript follows a process:

• check if p has sayHi
• if not, look at p.__proto__
• if still not found, continue up the chain

This is called the prototype chain.

p → Person.prototype → Object.prototype → null

The method is found not because it exists on p…

but because p knows where to search.

The Real Difference

At this point, the distinction becomes clearer.

• prototype belongs to the function
• __proto__ belongs to the object

And more importantly:

• prototype defines shared behavior
• __proto__ enables access to that behavior

One stores.

One links.

What Happens When You Change __proto__

Now imagine this:

p.__proto__ = {}

You didn’t delete anything.

Person.prototype still has sayHi.

But now the object is no longer connected to it.

So when you call:

p.sayHi()

JavaScript looks:

• inside p → not found
• inside {} → not found

And stops.

The method is still there.

But the path to it is gone.

Why Directly Using __proto__ Is Discouraged

Even though it works, using __proto__ directly is not recommended.

There are a few reasons.

First, it’s not the real mechanism.

It’s just a getter and setter for an internal concept called [[Prototype]].

Second, changing it dynamically can hurt performance.

JavaScript engines optimize objects based on stable structure.

Altering the prototype at runtime forces the engine to re-evaluate those optimizations.

And finally, it makes code harder to reason about.

You’re changing how objects inherit behavior after they’ve already been created.

That can quickly become confusing.

The Better Way

Instead of modifying the prototype chain later, it’s better to define it clearly from the beginning.

You can use:

Object.create(proto)

or:

Object.getPrototypeOf(obj)
Object.setPrototypeOf(obj, proto)

These are more explicit and safer.

A Different Way to Think About It

Instead of seeing objects as containers of methods…

it’s more accurate to see them as:

objects + a link to shared behavior

They don’t carry everything themselves.

They know where to look.

A Final Thought

prototype and __proto__ are not competing concepts.

They are two parts of the same system.

One defines what can be shared.

The other defines how it is accessed.

And once you see that connection…

JavaScript’s inheritance model stops feeling strange.

Because it’s not copying behavior.

It’s linking to it.