The JavaScript Engine & JIT Compilation
The problem
JavaScript source code is just text — something has to turn that text into instructions the CPU can actually execute, fast enough to keep a page interactive, without paying the full cost of a traditional ahead-of-time compiler every time a page loads.
Why now
Execution context and hoisting already described the setup a JavaScript engine performs before running code, treating the engine as a black box; this topic opens that box, explaining how the same engine can start running code almost instantly (via an interpreter) while getting faster the longer it runs (via just-in-time compilation).
Mental model
A JIT engine hedges its bets: it starts by interpreting code directly (slow per-operation, but zero compile delay), watches which functions run often, and compiles just those 'hot' functions down to optimized machine code on the fly — trading a small amount of upfront profiling for a large speedup on the code that actually matters, instead of compiling everything equally.
Requires
- Execution Context & HoistingJavaScript Runtime
This topic explains the mechanism underneath the execution-context setup already treated as given; you need that model as the black box before opening it up to see how it's actually implemented.
Unlocks
Used in
- V8 (Chrome, Node.js), SpiderMonkey (Firefox), and JavaScriptCore (Safari) — the major JIT engines
- Explaining why a function's performance can change (improve) the longer a program runs
- Understanding why consistent object shapes ('hidden classes') matter for engine optimization
- Benchmarking pitfalls — measuring 'cold' unoptimized code instead of realistic 'warmed up' performance
Projects
- Benchmark the same function's execution time on its first call versus after 100,000 calls in a loop, and explain the difference via JIT warm-up
- Research and explain, in your own words, what a 'hidden class' or 'shape' is in V8 and why keeping object shapes consistent helps performance
Examples
- A function called only once runs entirely interpreted; the same function called a million times in a hot loop gets compiled to optimized machine code partway through
- Adding properties to an object in inconsistent orders across instances can prevent an engine from optimizing them as efficiently as consistently-shaped objects
Resources
Mastery checklist
- I can explain the difference between interpretation and JIT compilation
- I can explain why a function's performance can improve the longer a program runs
- I can explain, at a high level, why consistent object shapes help engine optimization
- I can avoid a common benchmarking mistake by accounting for JIT warm-up