19. Browser engines compared: Blink/V8, Gecko/SpiderMonkey, WebKit/JavaScriptCore

An "engine" bundles a rendering engine (HTML/CSS parsing, layout, paint) and a JS engine. The three lineages in active use:

	Rendering engine	JS engine	Ships in
Chromium family	Blink (forked from WebKit in 2013)	V8	Chrome, Edge, Brave, Opera, Samsung Internet, Arc
Firefox	Gecko	SpiderMonkey	Firefox only
Safari / all iOS browsers	WebKit	JavaScriptCore	Safari, and — by Apple App Store policy until the EU's DMA forced an exception — every "Chrome" or "Firefox" on iOS, which are actually WebKit wrappers

Concrete engineering differences that surface as real bugs:

CSS feature timing: Blink ships experimental CSS behind flags fastest (largest market share, fastest iteration); Safari has historically lagged on features like :has(), container queries, and specific backdrop-filter behaviors — "works in Chrome" bug reports are overwhelmingly a WebKit gap.
Layout algorithm quirks: subpixel rounding, flexbox gap interpretation in older versions, and position: sticky inside overflow containers have all had genuinely different (spec-ambiguous) behavior across engines.
JS engine GC pause characteristics: V8's generational GC (§50) and JavaScriptCore's differ enough that the same allocation-heavy code can show different jank patterns per browser — a page smooth in Chrome can stutter in Safari purely from GC timing, not a logic bug.
Memory/process limits: mobile Safari (WebKit) has historically imposed much tighter per-tab memory ceilings than desktop Chrome, causing tab reloads on data-heavy SPAs that never reproduce on a developer's desktop Chrome.

Why this matters for testing: automated cross-browser testing (Playwright driving real Chromium, Firefox, and WebKit builds — not just "Chrome headless") is the only way to catch these; unit tests running in jsdom (which approximates a DOM but implements neither a real layout engine nor a real JS engine) cannot catch layout- or engine-specific bugs by construction.