The Lie of the JavaScript Object

If you do not understand how Shapes work you are writing code that forces the engine to abandon its optimizations and fall back to the slow path.

Consider this line of code.

const point = { x: 1, y: 2 };

Ask a developer what this is and if they will tell you it is a dictionary or a hash map. They will tell you that x and y are string keys that map to values and looking them up requires a hash calculation.

They are wrong.

To the V8 engine (which powers Chrome and Node.js) treating this object as a hash map is a failure state.

A hash map is slow. It involves computing a hash handling collisions and chasing pointers.

V8 wants speed. It wants to access point.x with a single machine instruction just like a C++ struct.

To achieve this V8 relies on a hidden machinery called Shapes (often called Hidden Classes or Maps).

If you do not understand how Shapes work you are writing code that forces the engine to abandon its optimizations and fall back to the slow path.

This article will tear down the abstraction of the JavaScript Object and reveal the transition trees and inline caches that live underneath.

What is a Shape?

JavaScript is a dynamic language. You can add or remove properties at runtime.

C++ is a static language. The memory layout is fixed at compile time.

V8 is a bridge that tries to make the former behave like the latter.

When you create an object V8 does not just allocate a bucket for keys and values. It allocates a Shape.

A Shape is a metadata descriptor. It contains

1. The property names (e.g. “x”).

2. The attributes of those properties (writable enumerable etc.).

3. Crucially The Offset where the value is stored in memory.

The Transition Tree

V8 builds these Shapes dynamically as you mutate objects. Let us trace the creation of our point object.

const point = {};

V8 starts with the Root Shape (Empty).

point.x = 1;

V8 sees a new property x. It cannot fit this into the Root Shape. It creates a new Shape (Shape A) that says “Offset 0 contains x”. It links the Root Shape to Shape A via a Transition (If you are at Root and add ‘x’ go to Shape A).

point.y = 2;

V8 sees y. It transitions from Shape A to Shape B. Shape B says “Offset 0 is x, Offset 1 is y”.

Now when you access point.y V8 does not calculate the hash of the string “y”. It looks at the Shape sees that y is at Offset 1 and reads the memory directly.

This is near-native speed.

The Performance Killer (Polymorphism)

The system works perfectly as long as your objects share the same Shape. But developers often break this mechanism without realizing it.

Consider these two objects

// Path 1
const a = {};
a.x = 1;
a.y = 2;

// Path 2
const b = {};
b.y = 2;
b.x = 1;

To a developer a and b are identical. They both have x and y.

But to V8 they are completely different entities.

Object a followed the transition chain, Empty -> Add x -> Add y. It creates Shape ID 1.

Object b followed the transition chain, Empty -> Add y -> Add x. It creates Shape ID 2.

Because the properties were initialized in a different order the offsets are different. In a, x is at offset 0. In b, x is at offset 1.

The Inline Cache (IC) Fail

This matters because of the Inline Cache.

When V8 runs a function that reads obj.x it “learns” the Shape of the object passed to it.

function getX(obj) {
    return obj.x;
}

Monomorphic State (Fastest)

If you always pass objects with Shape ID 1 V8 compiles a hot path. It says “I know this shape. x is always at offset 0. Just load memory index 0.” It strips out all checks.

This is the Monomorphic state.

Polymorphic State (Slower)

If you pass a (Shape 1) and then b (Shape 2) V8 invalidates the optimized code. It switches to a Polymorphic state.

It generates code that looks like a switch statement

• “If Shape 1 load offset 0.”

• “If Shape 2 load offset 1.” This adds CPU cycles for branching and checking.

Megamorphic State (The Cliff)

If you pass objects with 5 or more different Shapes (e.g. created via random assignment loops) V8 gives up.

It marks the call site as Megamorphic.

It stops trying to optimize offsets.

It falls back to Dictionary Mode.

It effectively treats the object as a hash map and performs a slow lookup for every single access. Your performance just fell off a cliff.

---

Takeaway

Static Initialization is King.

You cannot control the V8 compiler but you can control the Shapes it generates.

Initialize Properties in the Same Order

Always write your keys in the same sequence, here is a bad example of the same

if (condition) { 
  obj.a = 1; 
  obj.b = 2; 
} else { 
  obj.b = 2; 
  obj.a = 1; 
}

The good way to ensuring the transition path is deterministic.

Use Object Literals or Constructor

Using

class Point { constructor(x,y) { this.x = x; this.y = y; } }

guarantees that every instance follows the exact same transition chain.

Piecemeal assignment (obj.a = ...) is risky.

Avoid delete

Using the delete keyword typically forces V8 to abandon the Shape optimization entirely and revert the object to Dictionary Mode because the transition tree does not support “removing” a step efficiently.

If you need to remove a value set it to null or undefined instead.

You are not writing JavaScript for a browser.

You are writing JavaScript for a JIT compiler.

Treat your objects like Structs and the engine will reward you with C++ performance.

Treat them like Hash Maps and you will pay the dynamic language tax.

---