The engine landscape: V8, JSC, SpiderMonkey
The four engines that matter — V8, SpiderMonkey, JavaScriptCore, Hermes — share the same adaptive shape: interpreter plus tiered JIT plus GC. Why this track teaches V8, what transfers, and the terminology map across engines.
The hidden-class trick that makes your object property reads fast in Chrome works in Firefox and Safari too — but it’s called a “Shape” in Firefox and a “Structure” in Safari. Four production engines arrived at almost the same architecture independently. Learn one deeply and you can read all of them; the names change, the mechanism doesn’t.
By the end of this lesson you will know which engine runs your code, what the tiering ladder looks like across all four, and how to translate terminology when an article written for one engine describes a pattern you need for another.
Four engines, one architecture
There are four JavaScript engines you are likely to ship on:
- V8 (Google) — Chrome, Edge, Node.js, Deno, Electron, Cloudflare Workers. The most widely deployed; this track’s primary subject.
- SpiderMonkey (Mozilla) — Firefox. The oldest engine, written by Brendan Eich in 1995.
- JavaScriptCore / Nitro (Apple) — Safari, and the default engine in Bun. Known for an aggressive multi-tier JIT.
- Hermes (Meta) — React Native. Unusual: it compiles to bytecode ahead of time and ships that bytecode, optimising app start-up on mobile over peak throughput.
Despite independent teams and codebases, the first three converged on the same shape: a fast interpreter for cold code, one or more optimising JIT compilers for hot code driven by type feedback, hidden classes for fast property access, inline caches at call sites, and a generational garbage collector. That convergence is the reason this track is worth your time: it isn’t V8 trivia, it’s how dynamic languages are made fast.
The tiering ladder
Each engine runs code through tiers, trading compile cost for run speed. More invocations earns a higher tier:
V8’s ladder is Ignition → Sparkplug → Maglev → TurboFan. JavaScriptCore famously runs four tiers (LLInt → Baseline → DFG → FTL). SpiderMonkey runs Interpreter → Baseline → WarpMonkey. The shapes rhyme: cheap-and-general at the bottom, expensive-and-specialised at the top, with the engine promoting and demoting functions as their behaviour changes.
A short history (so version posts make sense)
V8 itself went through generations, and old blog posts assume the old design:
- 2008–2010: full-codegen + Crankshaft
- first JIT
- 2017: Ignition + TurboFan
- bytecode era
- 2021: Sparkplug
- baseline JIT
- 2023: Maglev
- mid-tier JIT
- Property-layout object (V8 term)
- Map
- Same concept in JSC / SpiderMonkey
- Structure / Shape
When you read a 2015 article about “Crankshaft” and “hidden classes,” the optimiser it describes is gone, but the hidden-class concept it teaches is still exactly right. This is why we anchor on mechanisms, not product names.
The terminology map
The single biggest source of confusion when reading across engines is naming. Same idea, three words:
- Hidden class (the object property-layout descriptor):
Mapin V8,Shapein SpiderMonkey,Structurein JavaScriptCore. - Small integer:
Smiin V8; tagged similarly elsewhere. - Deoptimisation (bailing from compiled code back to the interpreter):
deoptin V8,bailoutin JSC/SpiderMonkey.
This track uses V8’s vocabulary throughout. We will flag the cross-engine synonym the first time each appears.
V8, SpiderMonkey, and JavaScriptCore were built by separate teams. Why did they end up with such similar architectures?
Hermes ships pre-compiled bytecode instead of JIT-compiling at runtime. What is it optimising for?
Order V8's execution tiers from the cheapest-to-produce (runs first) to the most heavily optimised (runs only for the hottest code).
- 1 Ignition (interpret bytecode)
- 2 Sparkplug (baseline JIT)
- 3 Maglev (mid-tier JIT)
- 4 TurboFan (optimising JIT)
▸Edge cases
Bun uses JavaScriptCore, not V8. That means a microbenchmark tuned with V8 native flags (--allow-natives-syntax, %OptimizeFunctionOnNextCall) simply won’t run there, and a deopt pattern that bites in V8 may behave differently under JSC’s DFG/FTL tiers. The portable lesson survives the engine swap; the engine-specific tooling does not. Always note which engine your numbers came from.
- 01Name the four engines that matter and one host each ships in.
- 02What does 'hidden class' translate to in SpiderMonkey and JavaScriptCore?
- 03Why does this track anchor on mechanisms rather than product names like 'Crankshaft' or 'TurboFan'?
Four engines carry production JavaScript: V8 (Chrome, Node, Deno, Edge), SpiderMonkey (Firefox), JavaScriptCore (Safari, Bun), and Hermes (React Native). The first three independently converged on the same adaptive architecture — a cheap interpreter, one or more optimising JIT tiers driven by runtime type feedback, hidden classes for property layout, inline caches, and a generational garbage collector. V8’s tier ladder is Ignition → Sparkplug → Maglev → TurboFan; JSC and SpiderMonkey have their own equivalents. The vocabulary diverges (Map vs Shape vs Structure; deopt vs bailout), so we standardise on V8’s terms and flag synonyms. We teach V8 because it is the most deployed and best documented, but the mental model is portable. Now when you read a blog post that says “Shape” or “bailout”, you will know which V8 concept it maps to — and the lesson will transfer regardless of which engine your production traffic runs on.
Practice
Start at the top. Tasks go easiest → hardest: recall a fact, apply it to a case, then a senior-level stretch. Open one, attempt it, then reveal.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.