Part I — Foundations: the JS way
1. What JavaScript is, and the engines that run it
JavaScript was written by Brendan Eich at Netscape in 10 days in 1995. It
was rushed to market to make web pages "alive" (validate a form, animate a
menu) and deliberately made to look like Java for marketing reasons —
despite the two languages sharing almost nothing beyond syntax. That rushed
origin explains a surprising amount of the language's quirky behavior
(typeof null === "object", automatic semicolon insertion, == coercion
rules) that later specs couldn't remove without breaking the web.
ECMAScript is the standardized specification JavaScript implements (ECMA International, TC39 committee). "JavaScript" and "ECMAScript" are used almost interchangeably; version names you'll see in the wild:
| Name | Year | Notable additions |
|---|---|---|
| ES5 | 2009 | strict mode, Array.prototype.map/filter/reduce, JSON |
| ES6 / ES2015 | 2015 | let/const, classes, arrow functions, Promises, modules, template literals, destructuring |
| ES2017 | 2017 | async/await |
| ES2020 | 2020 | optional chaining ?., nullish coalescing ??, BigInt |
| ES2022 | 2022 | top-level await, class private fields (#x) |
| ES2023+ | 2023+ | Array.prototype.toSorted/with, incremental yearly additions |
TC39 ships one edition per year now; there's no "waiting for ES7" anymore — proposals move through stages 0→4 and ship independently once they reach Stage 4.
Engines are the programs that actually execute JS. Every browser (and Node.js, Deno, Bun) embeds one:
| Engine | Ships in | JIT tiers |
|---|---|---|
| V8 | Chrome, Edge, Opera, Node.js, Deno | Ignition (interpreter) → Sparkplug (baseline JIT) → Maglev → TurboFan (optimizing JIT) |
| SpiderMonkey | Firefox | Interpreter → Baseline → Ion (optimizing JIT) |
| JavaScriptCore (Nitro) | Safari, all iOS browsers (WebKit is mandated for all browsers on iOS by Apple) | LLInt (interpreter) → Baseline → DFG → FTL (optimizing JIT) |
All three converge on roughly the same idea: start executing quickly with a simple interpreter, watch which functions run hot, and recompile those to optimized machine code — because compiling everything ahead of time would make page load unacceptably slow, and interpreting everything forever would make hot loops unacceptably slow. §49 goes deep on V8's specific pipeline.
Real-world example. "Why does my code run fine in Chrome but is subtly slower/different in Safari?" — often it's not a bug, it's JavaScriptCore's different JIT heuristics and GC pause behavior. Cross-browser testing isn't optional if you ship to consumers; §19 covers the concrete engine differences that cause this.