Writing engine-friendly JavaScript

Look back across this whole module and one pattern repeats at every stage. Lazy parsing bet that most functions are regular enough in usage to defer. Hidden classes and inline caches bet that objects are regular enough in shape to specialize property access. TurboFan's speculative optimization bet that a variable is regular enough in type to compile without dynamic checks. The generational garbage collector bet that most objects are regular enough in lifetime to die young in a cheap nursery pass. None of these are separate tricks — they're the same trick, applied at a different layer: the engine is constantly betting that your code is more disciplined than the language technically requires, and it goes fast exactly when that bet pays off. This closing lesson turns that observation into a short list of concrete habits, each one derived from a specific earlier lesson — and one important caveat about how far to take them.

Keep object shapes stable

Hidden classes and inline caches established that V8 tracks an object's shape — which properties it has, in what order — and that repeated property accesses at the same code site get fast once V8 has seen that shape enough times to specialize for it. That specialization only holds if the shape stays the same. Adding a property after construction, deleting one, or building "the same kind of" object with properties assigned in a different order each time all produce a different hidden class, which either falls back to a slower generic lookup or forces the inline cache to track multiple shapes at once.

// Shape-unstable: three different hidden classes for "the same" object,
// because properties are added conditionally and in varying order.
function makePointBad(x, y, labeled) {
  const p = {};
  p.x = x;
  p.y = y;
  if (labeled) p.label = "point"; // sometimes present, sometimes not
  return p;
}

// Shape-stable: every point has the same properties, assigned in the
// same order, every time — one hidden class, monomorphic access everywhere.
function makePointGood(x, y, labeled) {
  return { x, y, label: labeled ? "point" : null }; // always present
}

The rule this derives is simple: initialize every property a constructor (or object literal) will ever have, in the same order, every time — and treat "adding a property later" and "deleting a property" as things to avoid on objects you expect to be created in bulk or accessed in a hot loop.

Keep call sites monomorphic

The same regularity argument applies one level up, at the function-call boundary. The JIT and deoptimization covered how TurboFan compiles a function by betting on the types it has actually observed at each call site. A call site that always sees the same argument types (and, for method calls, objects of the same shape) is monomorphic, and it's the case TurboFan optimizes best. A call site that sees varying types — sometimes a number, sometimes a string, sometimes different object shapes — is polymorphic or, in the worst case, megamorphic, and the optimizer either has to emit slower code that checks types every time or risk a deopt when an assumption breaks.

// Polymorphic: this function is sometimes called with numbers, sometimes
// with strings — TurboFan can't specialize add() around a single type.
function add(a, b) { return a + b; }
add(1, 2);
add("x", "y");
add(1, 2);
add("x", "y");

Keeping a hot function's argument types consistent — and, symmetrically, not passing it a mix of differently-shaped objects — is what keeps it monomorphic and eligible for the JIT's best-case output.

Avoid the known slow paths

A handful of specific patterns are worth knowing by name because they reliably push code off the fast path:

• Changing a variable's type in a hot loop — starting a loop counter or accumulator as a number and later assigning it a string or undefined forces the engine to widen its assumptions about that variable, undoing exactly the specialization value representation makes cheap for a stable Smi.
• Holey and mixed arrays. V8 tracks an array's elements kind — internally, whether it's packed or has holes, and whether its elements are Smis, doubles, or arbitrary values. A dense array of small integers with no gaps (PACKED_SMI_ELEMENTS) is the fastest kind; creating holes (const a = []; a[0] = 1; a[10] = 2;) or mixing element types ([1, "two", 3]) demotes the array to a slower, more general elements kind, and that demotion is one-directional — an array doesn't get faster again just because you stop poking holes in it.
• Leaking the arguments object. Historically, referencing arguments inside a function (beyond simple, directly-consumed uses) blocked some optimizations, because arguments aliases the function's actual parameters in ways that are awkward for the optimizer to reason about. Rest parameters (function f(...args)) give you the same capability without the legacy baggage, and are the better default regardless of engine version.

Minimize allocation in hot paths

Garbage collection made the mechanical case for this directly: every object your code allocates is something the young generation has to hold and the Scavenger has to eventually visit, and while a cheap scavenge is fast, it isn't free — enough allocation churn in a per-frame callback adds up to real collector pressure. The concrete habits are the same ones that lesson closed with: reuse objects and arrays across iterations of a hot loop or frame callback instead of constructing fresh ones every time, and reach for typed arrays (Float32Array, Int32Array, and friends) for bulk numeric data specifically because they store raw unboxed numbers rather than tagged, individually-boxed values — exactly why the canvas, WebAssembly, and Web Audio code elsewhere on this site leans on them so consistently.

Prefer the platform's built-ins

Array methods like map, filter, and sort, and built-ins like Math.max or JSON.parse, are implemented inside the engine itself, in C++, and have had enormous optimization effort put into them directly — including handling exactly the elements-kind and monomorphism concerns above internally. A hand-rolled equivalent in JavaScript starts from zero on all of that, and rarely beats the built-in once you account for real inputs at scale. Reaching for the built-in first is usually both clearer and faster, and it's one less place your code can accidentally introduce the exact anti-patterns this lesson just listed.

The honest caveat: measure, don't guess

Everything above is real and derivable from the mechanics this module has covered. It is also, in isolation, exactly the kind of advice that curdles into cargo-cult folklore — "always do X because it's faster" repeated for years after the engine that made X necessary has moved on. Two things are true at once, and holding both is the actual skill:

• V8 is extraordinarily good, and it keeps changing. Optimizations that mattered five years ago (certain function-inlining limits, older arguments-object restrictions, specific array-preallocation tricks) have in some cases been substantially improved or made moot by later V8 releases. Advice frozen from an old blog post or a old Stack Overflow answer can be stale against the engine actually running your code today.
• Premature micro-optimization has a real cost of its own — it trades away readability and maintainability for a performance difference that, for most code, is never on any critical path a user notices. The overwhelming majority of code in a real application runs rarely enough that none of this module's mechanics matter to it at all.

Synthesis: the whole module, one pipeline

Every lesson in this module has been one stage of the same journey from text to running machine code, and every rule above maps onto one of those stages:

1. Parse → AST — source becomes a tree, lazily, so most of your code is barely looked at until it runs.
2. Bytecode → Ignition — the baseline interpreter every function starts in, fast to produce, profiling as it goes.
3. The JIT and deoptimization — hot functions get compiled to speculative machine code that bets on observed types, with deopt as the safety valve when a bet breaks.
4. Hidden classes and inline caches — the mechanism that turns stable object shapes into fast property access.
5. Value representation — Smis inline for free, everything else boxed on the heap and paid for accordingly.
6. Garbage collection — the generational collector reclaiming what your allocations leave behind, at a cost that shows up as a pause if it runs long enough.
7. This lesson — the habits that keep your code riding the fast path at every one of those stages, and the discipline to verify it's actually needed before you bother.

The last tie-back: it all runs on one thread

The very last thread to pull, and it runs through this entire site: everything this module describes — parsing, interpreting, JIT-compiling, deoptimizing, collecting garbage — executes on the same single main thread that the event loop drives, one task at a time, run to completion. A JavaScript engine isn't a separate system sitting beside the event loop; it's the thing whose execution is the tasks the loop is running. Every lesson in this module and every lesson in that one are describing the same machine from two different angles — this module from the inside of a single task's execution, that one from the outside, task to task. Keeping code engine-friendly and keeping the main thread responsive turn out, at bottom, to be the same project.

Where the curriculum goes from here

This closes out the JS engine module, but the shape underneath it — a system optimizing for the common, regular case while keeping a correct fallback for everything else — is not unique to V8. You'll find the same shape in how a database plans a query around the common access pattern, in how a CDN bets that most requests are cache hits, and in every tiered system on this site that has a fast path and a slow path. Carry the specific mechanics from this module — parse, bytecode, JIT, shapes, values, GC — as one fully-worked example of that far more general idea.