Dossier - ecmascript-dossier

Preface: Why a Systems Programmer Should Care About JavaScript

The Unlikely Marriage of Low-Level Thinking and High-Level Chaos

The Cognitive Dissonance

You’ve spent years—perhaps decades—thinking in terms of registers, stack frames, and memory layouts. You understand that a program is ultimately a sequence of machine instructions, that data structures are arrangements of bytes in memory, and that performance comes from understanding what the hardware actually does. JavaScript, at first glance, seems to be the antithesis of everything you value.

JavaScript doesn’t care about memory alignment. It has garbage collection instead of manual memory management. It converts types implicitly, sometimes in ways that defy logic. The == operator can make [] == ![] evaluate to true. The language was designed in ten days, and it shows. For someone who appreciates the elegance of C’s simplicity or the brutal honesty of assembly language, JavaScript appears to be a cosmic joke.

The Uncomfortable Truth

Yet here we are. JavaScript is the most deployed runtime environment in human history. It runs on billions of devices—every smartphone, every laptop, every desktop computer with a web browser. It executes in environments you wouldn’t expect: embedded systems, IoT devices, databases (MongoDB), serverless functions, and even spacecraft. The V8 engine alone represents one of the most sophisticated JIT compiler infrastructures ever built, comparable in complexity to LLVM.

More importantly for you: JavaScript and WebAssembly are becoming the universal compilation targets. When you need your code to run anywhere—truly anywhere—you increasingly have two choices: target native machine code for each platform (x86-64, ARM, RISC-V, etc.) or target JavaScript/WebAssembly. The latter is often more practical.

The Strategic Position

JavaScript occupies a strategic position in computing infrastructure that cannot be ignored. It is:

• The assembly language of the web: Just as you might not write assembly directly but need to understand it, JavaScript is the bytecode that runs everywhere.

• A compilation target: TypeScript, CoffeeScript, ClojureScript, Elm, PureScript, and hundreds of other languages compile to JavaScript. WebAssembly is designed to run alongside it.

• A plugin mechanism: Many applications use JavaScript as an embedded scripting language (Photoshop, Unity, game engines, CAD software).

• An optimization target: Modern JavaScript engines perform sophisticated optimizations—type inference, inline caching, hidden classes—that rival static compilers.

If you’re building a transpiler, you need to understand JavaScript as a target. If you’re building a compiler, WebAssembly is increasingly the deployment mechanism. If you’re building tools, browser extensions are the distribution channel. Like it or not, this is the infrastructure layer of modern computing.

The Systems Perspective

This book takes a different approach than typical JavaScript tutorials. We’re not here to teach you how to build a todo list app or manipulate the DOM to create animated buttons. We’re treating JavaScript as a systems-level technology:

• The runtime as a virtual machine: Understanding the event loop, call stack, and heap allocation strategies.

• The language as a compilation target: Studying the AST, code generation, and optimization pipelines.

• The ecosystem as infrastructure: Package management, module systems, and build toolchains as analogous to linkers and loaders.

• The specification as documentation: Reading ECMA-262 the way you’d read the Intel SDM or the ARM Architecture Reference Manual.

This perspective reveals that JavaScript, despite its surface chaos, has underlying mechanisms that are comprehensible and even elegant when viewed through the right lens.

The WebAssembly Revolution

WebAssembly changes the equation fundamentally. It provides:

• A binary format: Compact, fast to parse, fast to validate.

• A stack machine model: Simple, deterministic, and easy to target from a compiler.

• Near-native performance: JIT-compiled to machine code with predictable performance characteristics.

• Language agnosticism: C, C++, Rust, Go, and dozens of other languages can compile to WebAssembly.

• Security: Sandboxed execution with capability-based security (via WASI).

WebAssembly is the first serious attempt at a portable, safe, fast binary format for code distribution since Java bytecode. Unlike Java, it’s succeeding because it doesn’t try to be a complete platform—it’s a compilation target that integrates with existing ecosystems.

For a systems programmer, WebAssembly is fascinating because it brings low-level concepts back to the web:

• Manual memory management: You allocate from linear memory, just like malloc.

• Static typing: i32, i64, f32, f64—no implicit conversions.

• Deterministic execution: No garbage collection pauses (unless you implement your own GC).

• Low-level control flow: Direct branches, computed jumps via tables.

It’s almost like someone took the good parts of a systems language and made them run in a browser.

What This Book Is (and Emphatically Isn’t)

What This Book Is

This is a technical manual for understanding JavaScript and WebAssembly from a compiler writer’s and systems programmer’s perspective. It assumes you have strong fundamentals in:

• Systems programming: You’ve written substantial code in C, C++, or similar languages.

• Computer architecture: You understand what machine code is, how CPUs execute instructions, and what assembly language looks like.

• Compilers: You’ve at least read about lexing, parsing, AST construction, and code generation, even if you haven’t built a complete compiler.

• Operating systems concepts: You know what virtual memory is, how processes work, and what system calls do.

With that foundation, we’ll explore:

1. The JavaScript language specification (ECMA-262) in detail, focusing on semantics rather than syntax.

2. The execution model: How JavaScript engines actually work—the JIT compilation pipeline, inline caching, hidden classes, garbage collection strategies.

3. The module systems: From global scope chaos to ES6 modules, CommonJS, and the Node.js runtime.

4. JavaScript as a compilation target: How to parse JavaScript, manipulate ASTs, and generate code.

5. WebAssembly’s design: The binary format, text format, type system, and execution model.

6. Building a WebAssembly compiler: How to translate from an intermediate representation to the Wasm stack machine.

7. Interoperability: How JavaScript and WebAssembly communicate, share memory, and call each other’s functions.

8. Practical applications: Browser extensions, userscripts, Node.js tooling, and WASI for server-side WebAssembly.

What This Book Isn’t

This is not:

• A web development tutorial: We won’t build React apps or discuss CSS frameworks.

• A beginner’s programming book: We assume you can program and understand algorithmic complexity.

• A JavaScript best practices guide: We care more about how things work than about style guides or linting rules.

• Framework-focused: No Angular, React, Vue, or any other frontend framework unless it illustrates a fundamental concept.

• A replacement for the specifications: We reference ECMA-262 and the WebAssembly spec extensively, but we can’t replace them. You should have both documents available.

The Tone and Approach

I’m going to be honest with you: JavaScript has warts. Many of them. We’ll point them out, explain why they exist (historical context matters), and show you how to work around them. We won’t pretend that 0.1 + 0.2 !== 0.3 is elegant—it’s an IEEE 754 consequence that every language faces, but JavaScript’s implicit coercion makes it more visible.

At the same time, we’ll acknowledge the genuine engineering achievements: V8’s TurboFan compiler is a marvel of optimization technology. The ES6 module system is actually well-designed. WebAssembly’s security model is sophisticated and practical.

This book has opinions, but they’re engineering opinions backed by technical reasoning. When we say something is poorly designed, we’ll explain why and what the alternatives would have been. When we say something is clever, we’ll show you the mechanism.

Practical Outcomes

By the end of this book, you should be able to:

1. Write a source-to-source compiler that targets JavaScript, handling scoping, closures, and the module system correctly.

2. Build browser extensions for Firefox and Chrome that do non-trivial work (not just DOM manipulation).

3. Create userscripts for Greasemonkey/Tampermonkey that can intercept and modify web traffic at the JavaScript level.

4. Understand the Node.js runtime well enough to build command-line tools, understand the event loop, and integrate with native C/C++ addons.

5. Read and understand ECMA-262: Navigate the specification, understand abstract operations, and predict behavior in edge cases.

6. Write WebAssembly by hand in the text format (WAT) for educational purposes.

7. Build a compiler backend that targets WebAssembly, handling function calls, linear memory, and the import/export system.

8. Debug WebAssembly in browser DevTools and understand the generated binary format.

9. Use WASI to run WebAssembly outside the browser with system interface access.

10. Understand JavaScript engine internals at a high level: what V8’s TurboFan does, how SpiderMonkey’s IonMonkey optimizes, and how these relate to traditional compiler technology.

These are practical skills that enable you to work at the intersection of high-level and low-level programming.

Your Background Assessment: C, Assembly, and the Unix Philosophy

What I’m Assuming You Know

Looking at your GitHub portfolio (https://github.com/Chubek), I can see projects involving:

• Compiler construction: Lexers, parsers, and code generation.

• Assembly language programming: x86, ARM, and potentially other architectures.

• Systems-level C/C++: Memory management, pointer manipulation, bit operations.

• Unix/Linux tools: Shell scripting, text processing, build systems.

• Language implementation: Interpreters, VMs, and runtime systems.

This tells me you think in terms of:

• Memory as a flat array of bytes: Addresses, pointers, and manual layout.

• Explicit control flow: Jumps, branches, and call/return mechanisms.

• Minimal abstractions: You prefer mechanisms you can see through.

• Tools as composable primitives: The Unix philosophy of small, focused utilities.

The Conceptual Bridge

JavaScript violates many of your intuitions:

The key to understanding JavaScript is realizing that it’s a high-level language with low-level implementation details that matter. The spec describes abstract operations, but V8 implements them with sophisticated compiler techniques. You need to understand both layers.

The Translation Guide

Throughout this book, I’ll provide “translation guides” that map JavaScript concepts to systems-level equivalents:

• Closures ↔︎ Stack frames captured on the heap

• Prototypes ↔︎ Vtable pointers with delegation

• The event loop ↔︎ select()/epoll() with callback queues

• Promises ↔︎ Continuation-passing style with state machines

• Typed Arrays ↔︎ Pointers to raw memory with typed access

• WebAssembly linear memory ↔︎ mmap()-allocated region

These analogies aren’t perfect, but they provide mental models that map to what you already know.

The Systems Programmer’s Advantage

You have advantages that web developers often lack:

1. You understand the cost of abstractions: When we discuss engine internals, you’ll grasp why certain patterns perform well.

2. You can read specifications: ECMA-262 uses algorithmic pseudocode similar to compiler textbooks.

3. You know binary formats: WebAssembly’s binary encoding will make immediate sense.

4. You understand ISAs: The WebAssembly instruction set is simpler than x86 or ARM.

5. You’re comfortable with low-level debugging: Understanding stack traces and heap dumps comes naturally.

Where web developers struggle with “why is this slow?”, you’ll be able to profile, understand deoptimization, and fix the root cause.

How to Use This Book

Reading Strategies

This book is designed to support multiple reading strategies:

Strategy 1: Linear Read (Recommended for First Pass)

Read chapters 1-18 in order. This builds concepts progressively:

• Chapters 1-3: Foundation—language semantics and execution model.

• Chapters 4-7: Core JavaScript—functions, objects, arrays, modules.

• Chapters 8-10: Runtime environments—browser, Node.js, extensions.

• Chapters 11-12: Transpilation—building compilers that target JavaScript.

• Chapters 13-17: WebAssembly—from fundamentals to building a compiler.

• Chapter 18: Engine internals—how JavaScript and WebAssembly are implemented.

Strategy 2: Goal-Oriented Read

Jump to the chapters that support your immediate goals:

• Goal: Build a transpiler → Chapters 1-2 (foundation), 7 (modules), 11-12 (transpilation)

• Goal: Browser extensions → Chapters 1-2 (foundation), 8 (browser environment), 10 (extensions)

• Goal: WebAssembly compiler → Chapters 1-2 (foundation), 13-16 (WebAssembly)

• Goal: Node.js tools → Chapters 1-2 (foundation), 7 (modules), 9 (Node.js)

• Goal: Understand engines → Chapters 1-3 (foundation), 18 (engines)

Strategy 3: Reference Use

Keep the book nearby while working on projects. Use the appendices for quick lookups:

• Appendix A: Syntax quick reference for when you forget the syntax.

• Appendix B: Feature compatibility for when you need to support older environments.

• Appendix C: WebAssembly instruction reference for when you’re hand-coding WAT.

• Appendix D: Tools and libraries for when you need to find the right library.

Working with the Specifications

Throughout the book, I reference:

• ECMA-262 (the JavaScript specification): ecma-262-std.pdf (847 pages)

• WebAssembly Specification: wasm-spec.pdf (321 pages)

These documents are dense but invaluable. I’ll teach you how to read them:

• ECMA-262 uses abstract operations (functions prefixed with !) and algorithmic steps. It’s actually quite readable once you understand the notation.

• WebAssembly Spec uses formal semantics (mathematical notation), which is more challenging but precise.

I’ll provide page references so you can cross-reference the specifications. For example:

The [[Environment]] internal slot of a function object (ECMA-262, §10.2.3, p. 203) stores the lexical environment in which the function was created, enabling closures.

This means you can turn to page 203 of ecma-262-std.pdf to see the actual specification text.

Code Examples and Conventions

All code examples follow these conventions:

JavaScript Code

// Comments explain what's happening
function example(parameter) {
    // We use modern ES6+ syntax by default
    const result = parameter * 2;
    return result;
}

WebAssembly Text Format (WAT)

;; Comments in WAT use semicolons
(module
    (func $example (param $parameter i32) (result i32)
        ;; Stack-based operations
        local.get $parameter
        i32.const 2
        i32.mul
    )
)

C/C++ (for comparison)

// C code for comparison when useful
int example(int parameter) {
    int result = parameter * 2;
    return result;
}

Shell Commands

# Commands you run in a terminal
npm install some-package
node script.js

Exercises and Experiments

Each chapter includes “Experiments” sections suggesting things to try. These are not traditional exercises with solutions—they’re explorations:

• Run this code in the browser console and observe the output.

• Modify this example and see what breaks.

• Use the debugger to step through execution.

• Read this section of the spec and see if you can understand it now.

I don’t provide solutions because the point is exploration and building intuition. When you modify code and it breaks in an unexpected way, that’s when you learn.

Online Resources

While I’ve tried to make this book comprehensive, you’ll need external resources:

1. MDN Web Docs (https://developer.mozilla.org): The best JavaScript reference.

2. Node.js Documentation (https://nodejs.org/docs): For Node.js-specific APIs.

3. WebAssembly.org (https://webassembly.org): Official WebAssembly documentation.

4. WABT (https://github.com/WebAssembly/wabt): WebAssembly Binary Toolkit for working with Wasm.

5. V8 Blog (https://v8.dev/blog): Deep dives into engine internals.

I’ll reference these throughout the book.

Feedback and Errata

This is a technical book about rapidly evolving technologies. JavaScript evolves yearly (ES2025, ES2026, etc.), and WebAssembly is still adding features. I’ve focused on:

• Stable features: Things unlikely to change (closures, prototypes, the event loop).

• Current standards: ES2025 and WebAssembly 3.0 as of publication.

• Timeless concepts: Compilation strategies, runtime models, and engineering trade-offs.

When new features arrive, the fundamentals we cover will help you understand them.

Acknowledgments

Standing on the Shoulders of Giants

This book wouldn’t exist without:

• Dr. Axel Rauschmayer’s “JavaScript for Impatient Programmers”: A clear, well-organized introduction that inspired parts of our structure.

• The ECMA TC39 Committee: For stewarding JavaScript’s evolution with care.

• The WebAssembly Community Group: For designing a remarkably elegant bytecode format.

• Engine Developers: The teams behind V8, SpiderMonkey, JavaScriptCore, and ChakraCore who push the boundaries of JIT compilation.

• The Open Source Community: For creating tools like Babel, Acorn, and WABT that make working with these technologies practical.

Personal Acknowledgments

To Chubek (the intended reader): I’ve studied your GitHub projects and tried to write the book I think you need. Your background in compilers, assembly, and systems programming is evident, and I’ve assumed that level of sophistication throughout. If I’ve misjudged, let me know—this book is for you.

To the broader systems programming community: Many of you are skeptical of JavaScript, and rightfully so. I hope this book convinces you that underneath the chaos, there’s interesting technology worth understanding. Not because you’ll love JavaScript (you might not), but because it’s infrastructure you can’t avoid, and infrastructure should be understood.

Tools and Environment

This book was written using:

• ECMA-262 16th Edition (June 2025): The authoritative JavaScript specification.

• WebAssembly Specification 3.0: The latest WebAssembly standard.

• Node.js v20+: For testing all code examples.

• Firefox Developer Edition and Chrome/Chromium: For browser-based examples.

• WABT (WebAssembly Binary Toolkit): For assembling and disassembling WebAssembly.

All code examples have been tested and work as shown (or fail in the instructive way described).

A Note on Attitude

If you’ve gotten this far, you’re committed to understanding JavaScript and WebAssembly despite your misgivings. That’s good. You don’t have to love these technologies—I’m not asking you to. But you should understand them with the same rigor you’d apply to any other systems-level technology.

JavaScript is messy, yes. It has more warts than most languages. But it’s also the result of decades of evolution, trillions of dollars of investment in engine optimization, and the collective work of thousands of talented engineers. Dismissing it as “toy language for web developers” is intellectually lazy.

WebAssembly, on the other hand, is a genuinely well-designed system. It learned from Java’s mistakes, avoided JavaScript’s legacy baggage, and provides a clean compilation target with strong security properties. It deserves your respect.

Let’s begin.

Today’s date: 1404/07/21 (Jalali) / 2025/10/13 (Gregorian)

Chapter 1: The ECMAScript Standard and Its Discontents

From Mocha to ES2025: A Brief, Opinionated History

The Ten-Day Language

In May 1995, Brendan Eich was hired by Netscape Communications Corporation with a specific mandate: create a scripting language for the web browser. The timeline was absurd—the company wanted it done in ten days. The result was Mocha, later renamed LiveScript, and finally JavaScript to capitalize on Java’s marketing momentum (despite having almost nothing in common with Java beyond some syntactic similarities).

This rushed creation explains many of JavaScript’s quirks. When you have ten days to design a language, you don’t have time to think through every edge case. You borrow liberally from existing languages—Scheme for first-class functions and closures, Self for prototypal inheritance, Java for syntax—and you ship it. The consequences of those hasty decisions compound over decades when backward compatibility becomes sacrosanct.

Systems Programmer’s Note: Imagine designing a processor ISA in ten days. You’d probably copy x86’s instruction encoding, ARM’s conditional execution, and MIPS’s delayed branches. Then imagine that ISA being frozen for 30 years with billions of devices depending on every quirk. That’s JavaScript’s predicament.

The Standardization Process (1997-1999)

By 1996, JavaScript was too important to remain a proprietary Netscape technology. Microsoft had reverse-engineered it as JScript for Internet Explorer, introducing subtle incompatibilities. The Browser Wars had begun, and developers were caught in the crossfire.

Netscape submitted JavaScript to Ecma International (a European standards body) in 1996. The Technical Committee 39 (TC39) was formed to standardize the language. The first edition of ECMA-262 was published in June 1997, codifying what would become known as ECMAScript 1.

Why “ECMAScript” and not “JavaScript”? Sun Microsystems (later acquired by Oracle) owned the trademark “JavaScript.” To avoid legal issues, the standard uses “ECMAScript” as the formal name. In practice, everyone still says “JavaScript.”

The timeline of early editions:

• ES1 (June 1997): The baseline. Standardized what Netscape Navigator 4 and IE 4 mostly agreed on.

• ES2 (June 1998): Editorial changes to align with ISO/IEC 16262.

• ES3 (December 1999): Added regular expressions, better string handling, try/catch, and other improvements. This became the stable base for years.

Then came ES4, the edition that never was.

The ES4 Debacle (2000-2008)

ES4 was ambitious—perhaps too ambitious. The committee wanted to add:

• Classes and classical inheritance: Moving away from prototypes.

• Modules: A proper module system instead of global scope pollution.

• Namespaces: Organizing code into hierarchical structures.

• Type annotations: Optional static typing.

• Generators and iterators: Lazy evaluation and custom iteration.

• Operator overloading: Custom behavior for +, *, etc.

This was a complete overhaul of the language. Microsoft, Yahoo, and others opposed it, arguing it was too complex and strayed too far from JavaScript’s roots. Adobe had ActionScript 3 (for Flash), which implemented many ES4 proposals, but the broader JavaScript community was divided.

The conflict became political. Two factions emerged:

1. ES4 maximalists: Led by Mozilla and Adobe, wanting a comprehensive upgrade.

2. ES3.1 minimalists: Led by Microsoft and Yahoo, wanting incremental improvements.

By 2008, it was clear ES4 wouldn’t pass. In a compromise, ES4 was abandoned, and ES3.1 became ES5. Some ES4 ideas (generators, modules, classes) would later appear in ES6, but in different forms.

Engineering Lesson: Standards by committee are slow, but that’s a feature, not a bug. Backward compatibility and consensus prevent one vendor from fragmenting the ecosystem. The price is conservatism and occasionally absurd compromises.

The Modern Era (ES5 to ES2025)

ES5 (December 2009)

ES5 brought modest but important improvements:

• Strict mode ("use strict";): Opts into stricter error checking and removes dangerous features.

• JSON: Native JSON.parse() and JSON.stringify().

• Array methods: map, filter, reduce, forEach, etc.

• Property descriptors: Fine-grained control over object properties (Object.defineProperty()).

• Getters and setters: Accessor properties.

ES5 was conservative, but it stabilized the language. It’s the last version universally supported without transpilation (though even old IE versions had spotty support).

ES6/ES2015: The Turning Point

ES6, officially named ES2015, was transformative. After years of stagnation, the committee delivered a massive upgrade:

• let and const: Block-scoped variables, finally!

• Arrow functions: Lexical this binding and concise syntax.

• Classes: Syntactic sugar over prototypes, but cleaner.

• Modules: import and export for proper modularity.

• Promises: Standardized asynchronous programming.

• Generators: Functions that can pause and resume (function*).

• Template literals: String interpolation with `Hello, ${name}`.

• Destructuring: Pattern matching for assignment.

• Rest/spread operators: ...args for functions and arrays.

• Symbols: A new primitive type for unique identifiers.

• Iterators and for...of: Standardized iteration protocol.

• Map, Set, WeakMap, WeakSet: New collection types.

• Typed arrays: Uint8Array, Int32Array, etc., for binary data.

ES6 was so large it took years for engines to fully implement. It marked the transition from “JavaScript is a toy language” to “JavaScript is a serious programming platform.”

The Yearly Release Cycle (ES2016-ES2025)

After ES6, TC39 adopted a yearly release cycle. Each edition is named by year: ES2016, ES2017, etc. Features are smaller and more focused:

• ES2016 (ES7): Array.prototype.includes(), exponentiation operator (**).

• ES2017 (ES8): async/await, Object.entries(), Object.values(), shared memory and atomics.

• ES2018 (ES9): Asynchronous iteration, rest/spread for objects, Promise.prototype.finally().

• ES2019 (ES10): Array.prototype.flat(), Object.fromEntries(), optional catch binding.

• ES2020 (ES11): Optional chaining (?.), nullish coalescing (??), BigInt, Promise.allSettled(), globalThis.

• ES2021 (ES12): Logical assignment operators (&&=, ||=, ??=), numeric separators (1_000_000), String.prototype.replaceAll().

• ES2022 (ES13): Class fields, private methods (#private), top-level await, Array.prototype.at().

• ES2023 (ES14): Array.prototype.findLast(), Array.prototype.toSorted(), hashbang grammar (#!/usr/bin/env node).

• ES2024 (ES15): Promise.withResolvers(), Object.groupBy(), ArrayBuffer transfer, well-formed Unicode strings.

• ES2025 (ES16): Regular expression modifiers, Set methods (.union(), .intersection()), duplicate named capture groups in regex.

Key Insight: The yearly cycle allows incremental evolution. TC39 uses a four-stage proposal process (Stage 0: Strawperson, Stage 1: Proposal, Stage 2: Draft, Stage 3: Candidate, Stage 4: Finished). Only Stage 4 proposals make it into the spec.

The Shadow History: Engines Drive Innovation

While TC39 standardizes, browser vendors innovate. V8 (Chrome/Node.js), SpiderMonkey (Firefox), and JavaScriptCore (Safari) compete on performance. Many language features emerged from engine experiments:

• V8’s hidden classes: Optimization technique that became foundational to modern JS performance.

• asm.js: Mozilla’s subset of JavaScript designed for AOT compilation, precursor to WebAssembly.

• Typed Arrays: Originally a WebGL requirement (need fast binary data), later standardized.

The relationship is symbiotic: engines push boundaries, TC39 standardizes what works, and the spec constrains engine behavior to ensure interoperability.

The ECMA-262 Document: Structure and Navigation

Obtaining the Specification

ECMA-262 is freely available at https://ecma-international.org/publications-and-standards/standards/ecma-262/. The document is published annually, with the most recent being the 16th Edition (June 2025)—referred to as ES2025.

Physical Properties: The PDF (ecma-262-std.pdf) is 847 pages. It’s dense, technical, and uses specialized notation. Don’t try to read it cover-to-cover; treat it as a reference manual.

High-Level Structure

The specification is organized into major sections:

Front Matter (Pages 1-24)

• Scope (§1, p. 1): One-paragraph overview of what ECMAScript is.

• Conformance (§2, pp. 1-2): What it means for an implementation to be conformant.

• Normative References (§3, p. 2): References to Unicode, ISO 8601 (dates), etc.

• Overview (§4, pp. 2-11): High-level description of the language, hosts (browser vs. Node.js), and terms.

• Notational Conventions (§5, pp. 11-24): How to read the spec’s algorithmic notation.

Systems Programmer’s Note: Think of this as the “Instruction Set Architecture” manual’s introductory chapters—defining notation, conventions, and scope before diving into opcodes.

Core Semantics (Pages 25-168)

• ECMAScript Data Types and Values (§6, pp. 25-62): Primitive types (Undefined, Null, Boolean, String, Symbol, Number, BigInt, Object) and specification types (internal constructs like Reference, Completion Record).

• Abstract Operations (§7, pp. 63-92): Reusable algorithms for type conversion, comparisons, and object operations. Think of these as the “standard library” of the spec itself.

• Syntax-Directed Operations (§8, pp. 93-136): How syntax maps to semantics (evaluation rules, scope analysis).

• Executable Code and Execution Contexts (§9, pp. 137-168): The runtime environment—how code executes, what an execution context is, the job queue, agents (threads), and realms.

Object Model (Pages 169-213)

• Ordinary and Exotic Objects Behaviours (§10, pp. 169-213): How objects work internally. Ordinary objects follow standard property access rules. Exotic objects (Arrays, bound functions, Proxies) have custom internal methods.

Key Concept: JavaScript objects have internal slots (like [[Prototype]], [[Extensible]]) and internal methods (like [[Get]], [[Set]]). These are specification mechanisms, not directly accessible in code.

Language Syntax and Semantics (Pages 214-699)

This is the bulk of the spec:

• Source Text (§11, pp. 214-217): How source code is interpreted (UTF-16, BOM handling).

• Lexical Grammar (§12, pp. 218-240): Tokens—identifiers, keywords, literals, operators.

• Expressions (§13, pp. 241-356): How expressions are parsed and evaluated.

• Statements and Declarations (§14, pp. 357-446): Control flow, loops, variable declarations.

• Functions and Classes (§15, pp. 447-522): Function definitions, arrow functions, class syntax.

• Scripts and Modules (§16, pp. 523-542): Top-level code execution, module imports/exports.

• Error Handling (§17, pp. 543-550): Native error types and throw/catch semantics.

Built-in Objects (Pages 551-826)

Every standard object (Object, Array, Function, Promise, Map, Set, etc.) is specified here:

• Fundamental Objects (§18-20): Object, Function, Boolean, etc.

• Numbers and Dates (§21-22): Number, BigInt, Math, Date.

• Text Processing (§23): String, RegExp.

• Indexed Collections (§24): Array, TypedArray.

• Keyed Collections (§25): Map, Set, WeakMap, WeakSet.

• Structured Data (§26): ArrayBuffer, DataView, Atomics, JSON.

• Managing Memory (§27): WeakRef, FinalizationRegistry.

• Control Abstraction Objects (§28-29): Iterators, generators, Promise, async/await.

• Reflection (§30): Reflect, Proxy, Module introspection.

Appendices (Pages 827-847)

• Grammar Summary (Annex A, pp. 827-835): Complete lexical and syntactic grammar in one place.

• Strict Mode (Annex C, p. 836): Differences between strict and sloppy mode.

• Corrections and Clarifications (Annex D, pp. 837-842): Changes from previous editions.

• Bibliography: References to Unicode, ISO standards, etc.

How to Navigate the Spec

Reading Algorithmic Steps

The spec uses a pseudocode notation called abstract operations. Example from §7.1.1 (ToPrimitive, p. 63):

ToPrimitive ( input [ , preferredType ] )

1. If Type(input) is Object, then
   1. If preferredType is not present, let hint be “default”.
   2. Else if preferredType is STRING, let hint be “string”.
   3. Else,
      1. Assert: preferredType is NUMBER.
      2. Let hint be “number”.
   4. Let exoticToPrim be ? GetMethod(input, @@toPrimitive).
   5. If exoticToPrim is not undefined, then
      1. Let result be ? Call(exoticToPrim, input, « hint »).
      2. If Type(result) is not Object, return result.
      3. Throw a TypeError exception.
   6. If hint is “default”, set hint to “number”.
   7. Return ? OrdinaryToPrimitive(input, hint).
2. Return input.

Notation guide:

• ?: Propagates exceptions. If the called operation returns an abrupt completion (error), this step returns immediately with that error.

• !: Asserts the operation never fails. Used when the spec guarantees success.

• [ , optional ]: Optional parameters.

• « »: A list (like an array).

• Type(x): Returns the type tag of x (Object, Number, etc.).

• @@toPrimitive: A well-known symbol (Symbol.toPrimitive).

Systems Analogy: This is like reading CPU microcode or a state machine definition. Each step is deterministic; follow them sequentially.

Finding Information Quickly

Use the table of contents (pp. i-x). It’s detailed. For example, to find how Array.prototype.map works:

1. Look up “Indexed Collections” → Section 24.

2. Navigate to § → “Array.prototype.map” (p. 588).

The spec has internal hyperlinks in the PDF. Click on a reference like “§7.1.1” to jump there.

Use the index (pages 827+). Search for “ToPrimitive,” “Completion Record,” “Lexical Environment,” etc.

Cross-Referencing with MDN

While ECMA-262 is authoritative, MDN Web Docs (https://developer.mozilla.org) is more readable for learning. MDN explains what and why; the spec explains how and edge cases.

Workflow:

1. Learn from MDN.

2. Verify behavior in the spec.

3. Understand nuances (like why [] == ![] is true) by tracing through abstract operations.

Internal Slots and Methods

JavaScript objects have internal slots (data) and internal methods (behavior). These are spec constructs, not accessible in code.

Example: Every function has:

• [[Environment]] (internal slot): The lexical environment where it was created (enables closures).

• [[Call]] (internal method): What happens when you invoke it.

Ordinary objects implement [[Get]] and [[Set]] for property access. Exotic objects (like Proxies) override these.

Systems Analogy: Internal slots are like private fields in a C++ class. Internal methods are virtual functions—exotic objects provide custom implementations.

Completion Records

Most abstract operations return a Completion Record, which is either:

• Normal completion: { [[Type]]: normal, [[Value]]: v }

• Abrupt completion: Errors, return, break, continue, etc.

The ? operator checks if a completion is abrupt and propagates it up the call stack.

Why this matters: Understanding Completion Records explains how exceptions work internally and why certain operations can fail.

TC39 and the Standards Process

Who is TC39?

Technical Committee 39 is the Ecma International committee responsible for ECMAScript. Members include:

• Browser vendors: Google (V8), Mozilla (SpiderMonkey), Apple (JavaScriptCore), Microsoft (formerly Chakra, now contributes to V8).

• Large tech companies: Facebook/Meta, Netflix, PayPal, Airbnb, Bloomberg.

• Individual experts: Academics, language designers, and community representatives.

TC39 meets every two months (in-person or remote) to discuss proposals.

The Proposal Process

New features follow a stage-based process:

Stage 0: Strawperson

Anyone can submit an idea. It’s just a concept, not a formal proposal. Many ideas die here.

Example: “What if JavaScript had pattern matching?”

Stage 1: Proposal

The committee agrees the problem is worth solving. A champion (a TC39 member or invited expert) takes ownership. The proposal needs:

• A clear problem statement.

• High-level API design.

• Potential challenges identified.

Example: Pattern matching reaches Stage 1 with a champion outlining use cases and syntax options.

Stage 2: Draft

The proposal has a formal specification text (written in ECMA-262 notation). The committee believes the feature will eventually be standardized, but details may change.

Engines may implement experimental versions (behind flags) for testing.

Example: Pattern matching gets draft spec text. V8 implements it behind --harmony-pattern-matching.

Stage 3: Candidate

The spec text is complete. Engines are expected to implement it for real-world testing. Only critical issues will cause changes.

Example: Pattern matching is implemented in Firefox Nightly and Chrome Canary. Feedback from developers refines edge cases.

Stage 4: Finished

The feature is ready for inclusion in the next annual release. Two independent implementations must exist, and significant real-world usage (or test262 tests) must validate it.

Example: Pattern matching ships in ES2026 after successful Stage 3 testing.

Consensus-Based Decision Making

TC39 operates by consensus, not majority vote. This means:

• Everyone must agree (or at least not object strongly enough to block).

• Compromises are common: Features are diluted or redesigned to satisfy objections.

• Progress is slow but stable: Hasty decisions (like ES4) don’t repeat.

Engineering Trade-off: Consensus prevents fragmentation but can lead to “design by committee” where elegant solutions are compromised for political reasons.

Test262: The Conformance Test Suite

Test262 (https://github.com/tc39/test262) is the official conformance test suite. It has over 70,000 tests covering every feature in ECMA-262.

Engines run Test262 to ensure compliance. If your JavaScript engine fails Test262, it’s not conformant.

For implementers: Test262 is your ground truth. If you’re building a JavaScript compiler or interpreter, you must pass Test262.

Strict vs. Sloppy Mode: Why It Matters to You

The Historical Accident

JavaScript was designed to be forgiving. If you forgot var, the variable became global. If you used reserved words as identifiers, it often worked. If you assigned to undefined, it silently failed.

This forgiveness was a mistake. It led to bugs, performance cliffs, and security issues. But backward compatibility meant these mistakes couldn’t be fixed without breaking the web.

Solution: ES5 introduced strict mode in 2009.

Enabling Strict Mode

Add "use strict"; at the top of a file or function:

"use strict";

function example() {
    // This function runs in strict mode
    x = 10; // ReferenceError: x is not defined
}

In ES6 modules, strict mode is implicit. You don’t need "use strict"; because modules are always strict.

// Inside an ES6 module file (imported via <script type="module">)
x = 10; // ReferenceError, even without "use strict"

Key Differences

Performance Implications

Strict mode enables optimizations:

• Hidden classes: Engines can assume properties don’t change unexpectedly.

• Inline caching: this in strict mode is more predictable.

• Elimination of arguments aliasing: Simplifies stack frame layout.

Benchmarks show strict mode can be 10-20% faster for certain workloads because the engine doesn’t have to handle edge cases.

When to Use Strict Mode

Always. There’s no reason to use sloppy mode in new code. ES6 modules enforce it automatically, and any modern tooling (eslint, TypeScript) defaults to strict.

Exception: You’re maintaining legacy code that depends on sloppy behavior. In that case, incrementally migrate to strict mode.

The Two Faces of JavaScript: Browser (Mobile) vs. Node.js (Resident)

Mobile ECMA-262: The Browser Environment

“Mobile” refers to JavaScript running in a browser, where it’s transient—code is downloaded, executed, and discarded. The environment provides:

• DOM APIs: document, window, Element, etc.

• Browser APIs: fetch, localStorage, WebSocket, WebRTC.

• Event-driven model: User clicks, network responses, timers.

• Security sandboxing: Same-origin policy, CSP, no file system access.

The browser is a hostile environment—your code runs alongside untrusted code from other origins, so security is paramount.

Key characteristics:

• No file system: You can’t open files directly.

• Limited persistence: localStorage is capped at ~5-10MB.

• Asynchronous everything: Network, user input, timers—all callback-based.

Resident ECMA-262: The Node.js Environment

“Resident” refers to JavaScript running on a server (or desktop) via Node.js, where it’s long-lived—the process stays up, handling requests or tasks continuously. Node.js provides:

• File system APIs: fs.readFile, fs.writeFile, etc.

• Network APIs: http, https, net, dgram (UDP).

• Process control: child_process, cluster, process.exit().

• Streams: Efficient I/O with backpressure.

Node.js is a trusted environment—you control the process, and it has full system access (with OS permissions).

Key characteristics:

• Full file system access: Read/write/delete files.

• Long-lived state: Variables persist across requests.

• Synchronous file operations: fs.readFileSync() blocks, unlike the browser.

The Common Core

Both environments implement ECMA-262, so core JavaScript is identical:

• Primitives, objects, functions, closures.

• Promises, async/await, generators.

• ES6 modules (with caveats).

Differences are in the host environment (DOM vs. Node.js APIs), not the language.

The Module System Divide

Browser: ES6 modules (import/export) are the standard, but CommonJS isn’t supported natively. Bundlers (Webpack, Rollup) transform modules for the browser.

Node.js: Originally used CommonJS (require()/module.exports). ES6 modules are now supported (since Node 12), but the ecosystem is split:

• .mjs files: ES6 modules.

• .cjs files: CommonJS modules.

• .js files: Depends on package.json "type": "module" or "type": "commonjs".

Systems Programmer’s Note: This is like the mess of linking C libraries—static vs. dynamic, .a vs. .so, name mangling. Node.js is trying to unify, but legacy code remains.

Tooling Overlap

Many tools work in both environments:

• Babel: Transpiles modern JavaScript to older versions.

• ESLint: Lints code for errors and style.

• Jest: Testing framework.

• Webpack: Bundles modules (primarily for browsers, but can target Node.js).

Performance Differences

V8 (Chrome/Node.js) uses the same engine, but:

• Browser: Optimizes for quick startup (website loads must be fast).

• Node.js: Optimizes for throughput (servers run continuously).

Garbage collection tuning differs:

• Browser: Frequent small GC pauses (don’t block rendering).

• Node.js: Fewer, larger GC pauses (throughput matters more than latency).

Reading the Spec Like a Compiler Writer

The Mindset Shift

If you’ve written compilers, you’re familiar with:

• Formal grammars: BNF, EBNF, or similar notation.

• Attribute grammars: Syntax with semantic rules attached.

• Operational semantics: Step-by-step execution rules.

ECMA-262 uses all three:

• Grammar: §12-16 define lexical and syntactic grammar (similar to BNF).

• Semantic rules: §8 defines syntax-directed operations (like attribute grammars).

• Abstract operations: §7 defines operational semantics (step-by-step algorithms).

Your advantage: You already think this way. The spec is just documentation of the abstract machine.

Example: Tracing Type Coercion

Let’s trace why [] == ![] is true:

1. Parse: [] == ![]

   • Left: [] (empty array)

   • Right: ![] (logical NOT of empty array)

2. Evaluate right side:

   • ![] → Is [] truthy? Yes (all objects are truthy). → !true → false.

3. Now we have: [] == false

4. Apply Abstract Equality (§7.2.15, p. 74):

   • Step 8: If one operand is Boolean, convert it to Number.

   • false → ToNumber(false) → 0.

   • Now: [] == 0.

5. Apply Abstract Equality again:

   • Step 10: If one operand is Object and the other is Number, convert Object to primitive.

   • [] → ToPrimitive([]) (§7.1.1, p. 63).

   • ToPrimitive([]) calls OrdinaryToPrimitive([], "number").

   • Tries valueOf(): [].valueOf() → [] (still an object).

   • Tries toString(): [].toString() → "" (empty string).

   • Now: "" == 0.

6. Apply Abstract Equality again:

   • Step 6: If one operand is String and the other is Number, convert String to Number.

   • "" → ToNumber("") → 0.

   • Now: 0 == 0.

7. Result: true.

Takeaway: By following the spec’s algorithmic steps, you can predict any JavaScript behavior. This is essential when writing a transpiler or debugging generated code.

Grammars in the Spec

The spec uses two grammars:

Lexical Grammar (§12)

Defines tokens: identifiers, keywords, literals, punctuation.

Example (§12.6.1, p. 221):

IdentifierName :: IdentifierStart IdentifierName IdentifierPart

IdentifierStart :: UnicodeIDStart $ _  UnicodeEscapeSequence

IdentifierPart :: UnicodeIDContinue $ _  UnicodeEscapeSequence

This says identifiers start with a Unicode ID start character, $, or _, and can contain those plus Unicode ID continue characters.

Systems Analogy: This is like the lexer rules in lex or flex.

Syntactic Grammar (§13-16)

Defines how tokens combine into statements and expressions.

Example (§13.5, p. 256):

ConditionalExpression[In, Yield, Await] : ShortCircuitExpression[?In, ?Yield, ?Await] ShortCircuitExpression[?In, ?Yield, ?Await] ? AssignmentExpression[+In, ?Yield, ?Await] : AssignmentExpression[?In, ?Yield, ?Await]

This defines the ternary operator: condition ? trueExpr : falseExpr.

The [In, Yield, Await] are grammar parameters (context-sensitive flags). For example, [+In] means “in” is allowed, [?In] means “inherit from parent.”

Systems Analogy: This is like yacc or bison grammar rules.

Semantic Rules: RS: Evaluation

Runtime Semantics: Evaluation (§8.1, p. 93) defines what each syntactic construct does.

Example (§13.5.1, p. 257):

ConditionalExpression : ShortCircuitExpression ? AssignmentExpression : AssignmentExpression

1. Let lref be ? Evaluation of ShortCircuitExpression.

2. Let lval be ToBoolean(? GetValue(lref)).

3. If lval is true, then

   1. Let trueRef be ? Evaluation of the first AssignmentExpression.
   2. Return ? GetValue(trueRef).

4. Else,

   1. Let falseRef be ? Evaluation of the second AssignmentExpression.
   2. Return ? GetValue(falseRef).

This says: evaluate the condition, convert to boolean, and evaluate one branch depending on the result.

Systems Analogy: This is like instruction semantics in an ISA manual—each instruction’s behavior is defined step-by-step.

Building a Mental Model

To use the spec effectively:

1. Start with MDN to understand high-level behavior.

2. Trace through the spec to understand edge cases.

3. Implement in code (a parser, interpreter, or transpiler) to solidify understanding.

4. Run Test262 to validate your implementation.

Example workflow:

• You’re implementing Array.prototype.map for your transpiler.

• Read MDN: “Calls a function on every element, returns new array.”

• Read ECMA-262 § (p. 588): See the exact algorithm (checks for callability, handles thisArg, handles sparse arrays).

• Implement based on the spec.

• Run Test262 tests for Array.prototype.map to catch edge cases.

The Spec Is Your Ground Truth

When JavaScript behaves unexpectedly:

• Don’t trust intuition: Trust the spec.

• Don’t trust Stack Overflow: Trust the spec (but SO can point you to the right section).

• Don’t trust the browser: If it contradicts the spec, it’s a browser bug (or you misread the spec).

The spec defines JavaScript. Everything else is commentary.

End of Chapter 1

In the next chapter, we’ll dive into JavaScript’s type system from a systems perspective—how primitives and objects are represented, how type coercion works at the algorithmic level, and why typeof lies to you.

Chapter 2: JavaScript’s Type System from a Systems Perspective

The Seven Language Types and Their Internal Representation

Introduction: Types as Tagged Unions

If you’ve worked in C, you’re familiar with tagged unions—a discriminated union where a tag indicates which variant is active:

enum TypeTag {
    TYPE_INT,
    TYPE_FLOAT,
    TYPE_POINTER
};

struct Value {
    enum TypeTag tag;
    union {
        int i;
        double f;
        void* ptr;
    } data;
};

JavaScript’s type system is conceptually similar. Every JavaScript value is a tagged union with one of seven possible types. The difference is that JavaScript hides the tag from you—you can’t directly access or manipulate it, though you can query it with typeof (which sometimes lies) or internal operations.

ECMA-262 §6.1 (p. 25) defines the seven language types:

1. Undefined – A singleton type with one value: undefined.

2. Null – A singleton type with one value: null.

3. Boolean – Two values: true and false.

4. String – Sequences of UTF-16 code units.

5. Symbol – Unique, immutable identifiers (ES6+).

6. Number – IEEE 754 double-precision floating-point.

7. BigInt – Arbitrary-precision integers (ES2020+).

8. Object – Collections of properties (wait, that’s eight!)

Actually, Object is special. The first six are primitive types—immutable, passed by value. Object is the only reference type—mutable, passed by reference.

Systems Insight: In most JavaScript engines (V8, SpiderMonkey), values are represented using pointer tagging or NaN boxing to pack the type tag into the pointer itself. More on this in §2.2.

Undefined: The Uninitialized Sentinel

Specification: §6.1.1 (p. 25)

undefined is the type of variables that have been declared but not assigned:

let x;
console.log(x); // undefined

Internal representation: In V8, undefined is represented as a special tagged pointer (kUndefinedValue). It’s a singleton—there’s only one undefined in memory.

Where you’ll see it:

• Uninitialized variables.

• Missing function arguments.

• Missing object properties.

• Functions that don’t explicitly return (implicitly return undefined).

Systems note: undefined is not the same as an uninitialized variable in C. In JavaScript, accessing an uninitialized variable that hasn’t been declared is a ReferenceError, not undefined:

console.log(y); // ReferenceError: y is not defined
let y;

This is because of the Temporal Dead Zone (TDZ)—let and const variables exist in scope but are uninitialized until their declaration is executed (§8.1.1.4.9, p. 124).

Null: The Intentional Absence

Specification: §6.1.2 (p. 25)

null represents the intentional absence of a value. It’s semantically different from undefined:

• undefined: “I haven’t been initialized yet.”

• null: “I explicitly have no value.”

let x = null; // Explicitly no value
let y;        // Implicitly undefined

The typeof null bug: One of JavaScript’s most infamous quirks:

typeof null; // "object" (WAT?!)

This is a bug from JavaScript’s original implementation. In the first JavaScript engine, values were represented as a type tag (3 bits) plus a value (32 bits on 32-bit systems). Objects had a type tag of 000, and null was represented as a null pointer (all zeros), so the type check incorrectly identified null as an object.

Brendan Eich has called this “the original sin” of JavaScript. It can’t be fixed without breaking millions of websites that depend on typeof null === "object".

Systems lesson: Early implementation decisions calcify into permanent language semantics when backward compatibility is sacrosanct.

Boolean: The Simple Case

Specification: §6.1.3 (p. 25)

true and false—nothing fancy here. Two singleton values.

Internal representation: In V8, booleans are immediate values (not heap-allocated). They’re represented as tagged pointers with a specific bit pattern.

Truthy and falsy: JavaScript has a concept of truthy and falsy values for use in conditional contexts. The falsy values are:

• false

• 0, -0, 0n (BigInt zero)

• "" (empty string)

• null

• undefined

• NaN

Everything else is truthy, including:

• "0" (non-empty string, even if it looks like zero)

• [] (empty array)

• {} (empty object)

• function() {} (any function)

Conversion to boolean: The abstract operation ToBoolean (§7.1.2, p. 64) defines this:

ToBoolean ( argument )

1. If argument is a Boolean, return argument.

2. If argument is undefined or null, return false.

3. If argument is a Number, then

   1. If argument is +0, -0, or NaN, return false.
   2. Otherwise, return true.

4. If argument is a String, then

   1. If argument is the empty String, return false.
   2. Otherwise, return true.

5. If argument is a Symbol or BigInt, return true.

6. If argument is an Object, return true.

Systems note: This is why [] == false can be true (§1.6 in Chapter 1)—the array is coerced to a primitive (""), which is then coerced to a number (0), which equals false coerced to a number (0). But if ([]) is always true because objects are truthy.

String: UTF-16 Code Units, Not Characters

Specification: §6.1.4 (pp. 25-27)

JavaScript strings are sequences of 16-bit unsigned integers, representing UTF-16 code units. They are immutable and primitives (not objects, despite having methods via autoboxing—see §2.8).

UTF-16 encoding: JavaScript predates Unicode’s expansion beyond the Basic Multilingual Plane (BMP). Originally, 16 bits per character was sufficient. When Unicode added code points beyond U+FFFF, UTF-16 introduced surrogate pairs—two 16-bit code units representing one character.

Example: The emoji 💩 (U+1F4A9) is represented as two code units:

const poop = "💩";
console.log(poop.length);           // 2 (not 1!)
console.log(poop.charCodeAt(0));    // 55357 (0xD83D, high surrogate)
console.log(poop.charCodeAt(1));    // 56489 (0xDCA9, low surrogate)

This is a footgun: String.prototype.length counts code units, not characters (grapheme clusters). For most ASCII text, they’re the same. For emoji, combining characters, or other BMP-external code points, they differ.

ES6 improvements:

• String.prototype.codePointAt(): Returns the full code point (handles surrogates).

• String.fromCodePoint(): Creates strings from code points.

• for...of iteration: Iterates by code points, not code units.

for (const char of "💩") {
    console.log(char); // Logs "💩" (one iteration)
}

Internal representation: Engines optimize string storage:

• Latin-1 encoding: If all characters are < 256, store as one byte per character.

• UTF-16 encoding: Otherwise, store as two bytes per code unit.

• Ropes: Concatenated strings can be stored as trees of substrings (lazy concatenation).

• Slices: Substrings can reference slices of parent strings without copying.

Systems note: JavaScript’s string model is awkward for modern Unicode text processing. If you’re building a transpiler that handles source code, you’ll need to be careful with positions—does your line/column counter use code units or code points? Source maps (§13.5) use zero-based code unit offsets.

Symbol: Unique, Unforgeable Identifiers

Specification: §6.1.5 (pp. 27-28)

Symbols were introduced in ES6 to solve the property key collision problem. Before symbols, all object property keys were strings. If you wanted to add a private or special property, you’d use a string like "__myPrivateProp" and hope no one else used the same name.

Symbols are unique: Every call to Symbol() creates a new, distinct symbol:

const sym1 = Symbol("description");
const sym2 = Symbol("description");
console.log(sym1 === sym2); // false

Symbols as property keys: You can use symbols as object property keys, and they won’t collide with string keys:

const mySymbol = Symbol("my-symbol");
const obj = {
    [mySymbol]: "value",
    "my-symbol": "different value"
};

console.log(obj[mySymbol]);     // "value"
console.log(obj["my-symbol"]);  // "different value"

Well-known symbols: The spec defines well-known symbols (§6.1.5.1, p. 28) for metaprogramming:

• Symbol.iterator: Defines the default iterator for an object (enables for...of).

• Symbol.toStringTag: Customizes Object.prototype.toString() behavior.

• Symbol.toPrimitive: Customizes type coercion (§7.1.1, p. 63).

• Symbol.hasInstance: Customizes instanceof behavior.

• And 10+ more.

Internal representation: Symbols are heap-allocated objects with a unique identifier. The “description” is just metadata for debugging—it doesn’t affect uniqueness.

Global symbol registry: Symbol.for(key) creates or retrieves a symbol from a global registry:

const sym1 = Symbol.for("app.id");
const sym2 = Symbol.for("app.id");
console.log(sym1 === sym2); // true (same symbol)

Systems use case: If you’re implementing object property access in a transpiler, you need to handle symbol keys differently from string keys. Symbol keys are not enumerable in for...in loops and don’t show up in Object.keys().

Number: IEEE 754 Double-Precision Floating-Point

Specification: §6.1.6 (pp. 28-31)

JavaScript’s Number type is IEEE 754-2019 binary64 (double-precision floating-point). This means:

• 64 bits total: 1 sign bit, 11 exponent bits, 52 mantissa bits (plus 1 implicit leading bit).

• Range: Approximately $\pm 1.7976931348623157 \times 10^{308}$.

• Precision: 15-17 significant decimal digits.

• Special values: +0, -0, +Infinity, -Infinity, NaN.

Why double-precision? JavaScript was designed for simple scripting, and doubles were “good enough” for most use cases. The assumption was that you wouldn’t need 64-bit integers (spoiler: you do, hence BigInt in ES2020).

The Integer Range Problem

Safe integer range: Integers can be represented exactly in the range $[-(2^{53} - 1), 2^{53} - 1]$. This is because the mantissa has 52 bits plus 1 implicit bit (53 bits total).

console.log(Number.MAX_SAFE_INTEGER); // 9007199254740991 (2^53 - 1)
console.log(Number.MIN_SAFE_INTEGER); // -9007199254740991 (-(2^53 - 1))

Beyond this range, not all integers can be represented exactly:

console.log(9007199254740992 === 9007199254740993); // true (WAT?!)

Both values round to the same double-precision representation.

Systems impact: If you’re implementing a compiler backend targeting JavaScript, you can’t use Number for 64-bit integers. You need BigInt (§2.1.7) or a custom library (like bn.js or bignumber.js).

Signed Zero

IEEE 754 has two zeros: +0 and -0. They compare as equal, but have different bitwise representations:

console.log(+0 === -0);         // true
console.log(1 / +0);            // Infinity
console.log(1 / -0);            // -Infinity
console.log(Object.is(+0, -0)); // false (Object.is distinguishes them)

Why signed zero exists: It preserves the sign of underflow in floating-point computations. For example, $\lim_{x \to 0^-} x = -0$.

Systems note: If you’re generating JavaScript code that performs floating-point math, be aware that -0 can appear unexpectedly (e.g., -1 * 0 === -0).

NaN: Not a Number (But Still a Number)

NaN represents the result of invalid operations:

console.log(0 / 0);         // NaN
console.log(Math.sqrt(-1)); // NaN
console.log(parseInt("foo")); // NaN

NaN is not equal to itself:

console.log(NaN === NaN); // false

This is per IEEE 754 spec—NaN is unordered, so any comparison with NaN (including NaN == NaN) returns false.

To check for NaN, use:

Number.isNaN(value);     // Strict check (ES6, preferred)
isNaN(value);            // Global function (coerces to Number first, don't use)
Object.is(value, NaN);   // Also works
value !== value;         // Classic hack (only NaN is not equal to itself)

Systems note: If you’re implementing numeric operations in your transpiler, you must handle NaN propagation correctly. For example, NaN + 1 === NaN, NaN * 0 === NaN, etc.

Infinity

Infinity and -Infinity represent overflow:

console.log(1 / 0);    // Infinity
console.log(-1 / 0);   // -Infinity
console.log(1e308 * 10); // Infinity (overflow)

Operations with Infinity:

• Infinity + 1 === Infinity

• Infinity * 2 === Infinity

• Infinity - Infinity === NaN (indeterminate form)

• Infinity / Infinity === NaN

Systems note: Infinity behaves like the IEEE 754 special value. If you’re compiling to JavaScript, be aware that integer overflow in the source language (e.g., C’s INT_MAX + 1) won’t translate directly—JavaScript will produce Infinity or wrap differently depending on the operation.

BigInt: Arbitrary-Precision Integers

Specification: §6.1.6.2 (pp. 31-34)

BigInt was added in ES2020 to address the Number type’s inability to represent large integers. BigInt values are arbitrary-precision integers—they can represent integers of any size (limited only by memory).

Creating BigInts:

const big1 = 1234567890123456789012345678901234567890n; // Literal suffix 'n'
const big2 = BigInt("1234567890123456789012345678901234567890");
const big3 = BigInt(123); // Convert Number to BigInt (must be integer)

Operations:

const a = 10n;
const b = 20n;

console.log(a + b);  // 30n
console.log(a * b);  // 200n
console.log(b / a);  // 2n (integer division, truncates)
console.log(b % a);  // 0n
console.log(a ** b); // 100000000000000000000n (10^20)

No mixing with Number:

console.log(10n + 20);  // TypeError: Cannot mix BigInt and other types

You must explicitly convert:

console.log(10n + BigInt(20)); // 30n
console.log(Number(10n) + 20); // 30 (converts BigInt to Number, may lose precision)

Comparisons work across types:

console.log(10n == 10);  // true (abstract equality coerces)
console.log(10n === 10); // false (strict equality doesn't coerce)
console.log(10n < 20);   // true (relational comparison coerces)

Internal representation: BigInts are heap-allocated objects with dynamically-sized digit arrays. In V8, small BigInts (fitting in a word) are stored inline; large ones are stored as arrays of 32-bit or 64-bit digits (depending on architecture).

Systems use case: If you’re compiling a language with 64-bit integers (C, Rust, Go) to JavaScript, you have two options:

1. Use Number for the safe integer range ($[-(2^{53}-1), 2^{53}-1]$) and error/wrap on overflow.

2. Use BigInt for all integers, accepting the performance cost (BigInt operations are slower than Number).

Emscripten (C/C++ to WebAssembly) originally used asm.js with 32-bit integers. For 64-bit integers, it used a pair of 32-bit values. With WebAssembly, 64-bit integers are native (i64 type).

Object: The Reference Type

Specification: §6.1.7 (pp. 34-43)

Object is the catch-all type for everything that’s not a primitive. This includes:

• Plain objects: { key: value }

• Arrays: [1, 2, 3]

• Functions: function() {}

• Dates: new Date()

• RegExps: /pattern/

• Maps, Sets, WeakMaps, WeakSets

• Promises

• And more.

Key distinction: Primitives are immutable and passed by value. Objects are mutable and passed by reference:

let a = 5;
let b = a;
b = 10;
console.log(a); // 5 (unchanged)

let obj1 = { x: 5 };
let obj2 = obj1;
obj2.x = 10;
console.log(obj1.x); // 10 (mutated!)

Internal structure: Objects are collections of properties. Each property has:

• Key: String or Symbol.

• Value: Any JavaScript value.

• Attributes: [[Writable]], [[Enumerable]], [[Configurable]].

Properties are either data properties (have a value) or accessor properties (have a getter/setter).

Property descriptors (§6.2.5, pp. 45-46):

const obj = {};
Object.defineProperty(obj, "x", {
    value: 42,
    writable: false,
    enumerable: true,
    configurable: false
});

console.log(obj.x); // 42
obj.x = 100;        // Fails silently in sloppy mode, TypeError in strict mode
console.log(obj.x); // Still 42

Internal slots and methods: Objects have internal slots (data) and internal methods (behavior). For example:

• [[Prototype]]: The object’s prototype (for inheritance).

• [[Get]]: Invoked when accessing a property.

• [[Set]]: Invoked when assigning to a property.

• [[Call]]: Invoked when calling a function (functions are callable objects).

These are specification mechanisms, not directly accessible in code. You interact with them via built-in methods like Object.getPrototypeOf() or Reflect API.

Ordinary vs. exotic objects:

• Ordinary objects: Follow standard property access semantics.

• Exotic objects: Have custom internal methods. Examples:

  • Arrays: Custom [[DefineOwnProperty]] to update length.

  • Functions: Have [[Call]] and [[Construct]].

  • Proxy: Intercepts all internal methods.

  • Bound functions: Custom [[Call]] to bind this.

We’ll cover objects in depth in Chapter 3. For now, understand that Object is the foundation of JavaScript’s type system.

Pointer Tagging and NaN Boxing: How Engines Optimize Values

The Problem: Representing Dynamic Types Efficiently

JavaScript values have dynamic types—a variable can hold any type at runtime. The naive approach is a struct with a type tag and a union:

struct JSValue {
    enum { UNDEFINED, NULL, BOOL, NUMBER, STRING, OBJECT, SYMBOL, BIGINT } tag;
    union {
        bool boolean;
        double number;
        char* string;
        JSObject* object;
        // ...
    } data;
};

But this wastes space:

• Size: On a 64-bit system, enum is 4 bytes (aligned to 8), union is 8 bytes (for a pointer or double). Total: 16 bytes per value.

• Cache efficiency: Larger values mean fewer fit in CPU cache lines.

JavaScript engines need to optimize this. The two main techniques are pointer tagging and NaN boxing.

Pointer Tagging (V8’s Smi)

Pointer tagging exploits the fact that pointers are aligned—on a 64-bit system, heap-allocated objects are aligned to 8-byte boundaries, so the low 3 bits of a pointer are always 0.

V8’s Smi (Small Integer): If a value is a small integer (31 bits on 32-bit systems, 32 bits on 64-bit systems), V8 stores it directly in the pointer with the low bit set to 1 to distinguish it from a pointer:

Smi: [31-bit integer][1] (low bit is 1) Pointer: [61-bit address][000] (low 3 bits are 0)

Example (64-bit system):

• The integer 42 is stored as 42 << 1 | 1 = 85 = 0x55.

• A pointer 0x7ffeefbff000 stays as-is (low bits are 0).

Advantages:

• Fast integer operations: Check the low bit. If it’s 1, it’s a Smi. Perform arithmetic directly on the tagged value (shift to extract, operate, shift back).

• No heap allocation: Smis are immediate values.

Limitations:

• Range: Smis can only represent $[-(2^{31}), 2^{31}-1]$ on 64-bit systems (one bit is used for the tag, one for the sign).

• Overflow: If an integer exceeds the Smi range, it must be boxed (heap-allocated as a HeapNumber).

Other tagged values: V8 also uses specific pointer values for singletons:

• undefined: A specific tagged pointer.

• null: Another specific tagged pointer.

• true/false: Tagged pointers.

NaN Boxing (SpiderMonkey, JavaScriptCore)

NaN boxing exploits the fact that IEEE 754 doubles have many NaN representations. In IEEE 754:

• Exponent bits all 1 (0x7FF) and mantissa non-zero → NaN.

• There are $2^{52}$ possible NaN bit patterns, but JavaScript only needs one canonical NaN.

Idea: Use the remaining NaN bit patterns to encode other types.

JavaScriptCore’s encoding (simplified, 64-bit):

NaN patterns (exponent = 0x7FF):

• 0x7FF8_0000_0000_0000: Canonical NaN

• 0x7FF0_0000_0000_0001 to 0x7FF7_FFFF_FFFF_FFFF: Unused NaN patterns

Encoding:

• Doubles: Normal IEEE 754 (if not in the reserved NaN range).

• Integers: Store as a double (if representable exactly).

• Pointers: Use reserved NaN patterns.

• Special values (undefined, null, true, false): Use reserved NaN patterns.

Example encoding:

undefined: 0xFFFF_FFFF_FFFF_FFF2 null: 0xFFFF_FFFF_FFFF_FFF3 true: 0xFFFF_FFFF_FFFF_FFF4 false: 0xFFFF_FFFF_FFFF_FFF5 Pointer: 0xFFFF_xxxx_xxxx_xxxx (where xxxx is the pointer value) Double: Normal IEEE 754 (0x0000_xxxx_xxxx_xxxx to 0x7FEF_xxxx_xxxx_xxxx and negatives)

Advantages:

• Uniform 64-bit representation: Every value fits in 64 bits.

• No extra type tag: The value itself encodes the type.

Disadvantages:

• Pointer range limitation: On 64-bit systems, only 48 bits of address space are typically used (x86-64 canonical addresses), so pointers fit. But if the address space expands, this breaks.

• Complexity: Bit manipulation is required for every value access.

Which Technique Does Each Engine Use?

• V8 (Chrome, Node.js): Pointer tagging (Smi + heap objects).

• SpiderMonkey (Firefox): NaN boxing (called “nunboxing” in SpiderMonkey).

• JavaScriptCore (Safari): NaN boxing.

• ChakraCore (old Edge): Pointer tagging (deprecated; Edge now uses V8).

Systems takeaway: When compiling to JavaScript, you generally don’t need to care about these details—engines handle it. But understanding them helps explain why:

• Small integers are fast (Smi in V8).

• Large integers or non-integer numbers are slower (heap-allocated).

• Operations that cause boxing/unboxing (e.g., Smi overflow) have performance cliffs.

The Type() Abstract Operation: How the Spec Classifies Values

Specification: §6.1 (p. 25)

The Type(x) abstract operation returns the type tag of a value. It’s not exposed to JavaScript code, but it’s fundamental to understanding the spec.

Definition:

Type ( x )

Returns one of: Undefined, Null, Boolean, String, Symbol, Number, BigInt, Object.

Examples:

• Type(undefined) → Undefined

• Type(null) → Null

• Type(true) → Boolean

• Type("hello") → String

• Type(Symbol()) → Symbol

• Type(42) → Number

• Type(42n) → BigInt

• Type({}) → Object

• Type([]) → Object

• Type(function() {}) → Object

Note: Arrays and functions are Objects. There’s no separate Array or Function type at this level. To distinguish them, you check internal slots like [[Call]] (for functions).

The typeof Operator: JavaScript’s Unreliable Type Query

Specification: §13.5.3 (p. 260)

The typeof operator is JavaScript’s user-facing type query. It mostly matches Type(), but with quirks:

console.log(typeof undefined);       // "undefined"
console.log(typeof null);            // "object" (BUG!)
console.log(typeof true);            // "boolean"
console.log(typeof "hello");         // "string"
console.log(typeof Symbol());        // "symbol"
console.log(typeof 42);              // "number"
console.log(typeof 42n);             // "bigint"
console.log(typeof {});              // "object"
console.log(typeof []);              // "object"
console.log(typeof function() {});   // "function"
console.log(typeof Math.sqrt);       // "function"

Discrepancies:

1. typeof null === "object": Bug from JavaScript’s original implementation (§2.1.2).

2. typeof function() {} === "function": Functions are Objects internally, but typeof distinguishes them.

Why “function” is a special case: The spec explicitly checks for [[Call]] (§13.5.3, p. 260):

typeof operator

12. If val has a [[Call]] internal method, return “function”.

13. Return “object”.

Reliable Type Checking

To reliably check types:

For primitives:

value === undefined                 // Check for undefined
value === null                      // Check for null
typeof value === "boolean"          // Boolean
typeof value === "string"           // String
typeof value === "symbol"           // Symbol
typeof value === "number"           // Number
typeof value === "bigint"           // BigInt

For objects, use:

Array.isArray(value)                      // Array
typeof value === "function"               // Function
value instanceof Date                     // Date
value instanceof RegExp                   // RegExp
value instanceof Promise                  // Promise
Object.prototype.toString.call(value)     // Generic (returns "[object Type]")

Example:

Object.prototype.toString.call([]);        // "[object Array]"
Object.prototype.toString.call(new Date()); // "[object Date]"
Object.prototype.toString.call(/regex/);    // "[object RegExp]"

Why Object.prototype.toString? It uses the [[Class]] internal property (legacy term; now called Symbol.toStringTag). Objects can customize this:

const obj = {
    [Symbol.toStringTag]: "MyCustomType"
};
console.log(Object.prototype.toString.call(obj)); // "[object MyCustomType]"

Systems note: If you’re implementing type guards in a transpiler, you’ll need to emit code that handles these quirks. For example, checking for null requires value === null, not typeof value === "object".

Type Coercion: The Algorithmic Nightmare

Why Coercion Exists

JavaScript was designed for non-programmers. Brendan Eich wanted it to be forgiving—if you write "5" + 2, it shouldn’t error; it should “do something reasonable.”

The problem: “reasonable” is subjective. JavaScript’s coercion rules are Byzantine, full of edge cases, and the source of endless bugs.

Two kinds of coercion:

1. Explicit coercion: You manually convert types (Number("5"), String(42)).

2. Implicit coercion: JavaScript converts types automatically ("5" + 2, if (value)).

Implicit coercion is where the madness lies.

The Big Three: ToString, ToNumber, ToBoolean

The spec defines three core coercion operations:

ToString (§7.1.17, pp. 71-72)

Converts a value to a string.

Algorithm (simplified):

ToString ( argument )

1. If argument is a String, return argument.

2. If argument is a Symbol, throw TypeError.

3. If argument is undefined, return “undefined”.

4. If argument is null, return “null”.

5. If argument is true, return “true”.

6. If argument is false, return “false”.

7. If argument is a Number, return NumberToString(argument).

8. If argument is a BigInt, return BigIntToString(argument).

9. If argument is an Object, return ? ToString(? ToPrimitive(argument, STRING)).

Examples:

String(undefined);      // "undefined"
String(null);           // "null"
String(true);           // "true"
String(42);             // "42"
String(42n);            // "42"
String({});             // "[object Object]" (calls ToPrimitive, then toString)
String([1, 2, 3]);      // "1,2,3"
String(Symbol("x"));    // TypeError!

Key insight: Objects are converted via ToPrimitive (§7.1.1, p. 63), which tries valueOf(), then toString().

ToNumber (§7.1.4, pp. 65-67)

Converts a value to a number.

Algorithm (simplified):

ToNumber ( argument )

1. If argument is a Number, return argument.

2. If argument is a Symbol or BigInt, throw TypeError.

3. If argument is undefined, return NaN.

4. If argument is null, return +0.

5. If argument is true, return 1.

6. If argument is false, return +0.

7. If argument is a String, parse it as a number (details in §7.1.4.1).

8. If argument is an Object, return ? ToNumber(? ToPrimitive(argument, NUMBER)).

Examples:

Number(undefined);      // NaN
Number(null);           // 0 (WAT?!)
Number(true);           // 1
Number(false);          // 0
Number("42");           // 42
Number("42.5");         // 42.5
Number("  42  ");       // 42 (trims whitespace)
Number("");             // 0 (empty string is 0)
Number("hello");        // NaN
Number([]);             // 0 ([] -> "" -> 0)
Number([5]);            // 5 ([5] -> "5" -> 5)
Number([1, 2]);         // NaN ([1,2] -> "1,2" -> NaN)
Number({});             // NaN ({} -> "[object Object]" -> NaN)
Number(Symbol("x"));    // TypeError!
Number(42n);            // TypeError!

Why Number(null) === 0? Historical accident. In JavaScript’s original implementation, null was treated as “nothing,” which coerced to 0. It’s a terrible decision but unchangeable due to backward compatibility.

ToBoolean (§7.1.2, p. 64)

Converts a value to a boolean (covered in §2.1.3).

Falsy values: false, 0, -0, 0n, "", null, undefined, NaN.

Everything else: Truthy.

ToPrimitive: The Object-to-Primitive Dance

Specification: §7.1.1 (pp. 63-64)

When JavaScript needs to coerce an object to a primitive (for arithmetic, string concatenation, etc.), it calls ToPrimitive:

ToPrimitive ( input [ , preferredType ] )

1. If input is not an Object, return input.

2. If preferredType is not present, let hint be “default”.

3. Else if preferredType is STRING, let hint be “string”.

4. Else, let hint be “number”.

5. Let exoticToPrim be ? GetMethod(input, @@toPrimitive).

6. If exoticToPrim is not undefined, then

   1. Let result be ? Call(exoticToPrim, input, « hint »).
   2. If result is not an Object, return result.
   3. Throw TypeError.

7. If hint is “default”, set hint to “number”.

8. Return ? OrdinaryToPrimitive(input, hint).

OrdinaryToPrimitive (§7.1.1.1, p. 64):

OrdinaryToPrimitive ( O, hint )

1. If hint is “string”, then
   1. Let methodNames be « “toString”, “valueOf” ».
2. Else,
   1. Let methodNames be « “valueOf”, “toString” ».
3. For each name in methodNames, do
   1. Let method be ? Get(O, name).
   2. If IsCallable(method), then
      1. Let result be ? Call(method, O).
      2. If result is not an Object, return result.
4. Throw TypeError.

Translation:

• If hint is "string", try toString() first, then valueOf().

• If hint is "number" or "default", try valueOf() first, then toString().

• If both return objects, throw TypeError.

Examples:

const obj = {
    valueOf() { return 42; },
    toString() { return "hello"; }
};

Number(obj);  // 42 (hint is "number", tries valueOf first)
String(obj);  // "hello" (hint is "string", tries toString first)
obj + "";     // "42" (hint is "default", which becomes "number")

Custom Symbol.toPrimitive:

const obj = {
    [Symbol.toPrimitive](hint) {
        if (hint === "number") return 42;
        if (hint === "string") return "hello";
        return "default";
    }
};

Number(obj);  // 42
String(obj);  // "hello"
obj + "";     // "default"

Systems note: If you’re transpiling a language with operator overloading to JavaScript, you might emit code that defines Symbol.toPrimitive.

Abstract Equality (==) vs. Strict Equality (===)

Specification: §7.2.15 (pp. 74-75) for ==, §7.2.16 (p. 75) for ===.

Strict Equality (===)

No coercion. Types must match:

x === y

1. If Type(x) is different from Type(y), return false.

2. If Type(x) is Number or BigInt, compare numerically (handle NaN, ±0).

3. Return SameValueNonNumeric(x, y) (reference comparison for Objects, value comparison for primitives).

Examples:

5 === 5;            // true
5 === "5";          // false (different types)
NaN === NaN;        // false (NaN is unordered)

+0 === -0;          // true
[] === [];          // false (different object references)

Abstract Equality (==)

Coercion madness. The algorithm is 12 steps (§7.2.15, pp. 74-75). Simplified version:

x == y

1. If Type(x) is the same as Type(y), return x === y.

2. If x is null and y is undefined (or vice versa), return true.

3. If x is Number and y is String, return x == ToNumber(y).

4. If x is String and y is Number, return ToNumber(x) == y.

5. If x is BigInt and y is String, convert String to BigInt and compare.

6. If x is Boolean, return ToNumber(x) == y.

7. If y is Boolean, return x == ToNumber(y).

8. If x is Object and y is primitive, return ToPrimitive(x) == y.

9. If y is Object and x is primitive, return x == ToPrimitive(y).

10. Otherwise, return false.

Examples:

null == undefined;  // true (special case)
5 == "5";           // true (coerces "5" to 5)
0 == false;         // true (false -> 0)
"" == false;        // true ("" -> 0, false -> 0)
[] == false;        // true ([] -> "" -> 0, false -> 0)
[] == ![];          // true (Chapter 1 example: [] -> 0, ![] -> false -> 0)
"0" == false;       // true ("0" -> 0, false -> 0)
"0" == 0;           // true ("0" -> 0)
0 == "0";           // true (symmetric)
false == "false";   // false ("false" -> NaN, false -> 0)

Why [] == ![] is true (§1.6 in Chapter 1):

1. ![] → false (objects are truthy).

2. [] == false.

3. false → 0 (step 7).

4. [] == 0.

5. [] → ToPrimitive([]) → "" (step 8).

6. "" == 0.

7. "" → 0 (step 3).

8. 0 == 0 → true.

Engineering lesson: Never use == unless you explicitly need coercion (rare). Always use ===.

Relational Comparisons (<, >, <=, >=)

Specification: §7.2.14 (pp. 73-74)

Relational operators coerce to primitives (with hint "number"), then compare:

x < y

1. Let px be ? ToPrimitive(x, NUMBER).

2. Let py be ? ToPrimitive(y, NUMBER).

3. If px and py are Strings, compare lexicographically.

4. Else, convert both to Number and compare numerically.

Examples:

5 < 10;             // true
"5" < 10;           // true ("5" -> 5)
"10" < "5";         // true (lexicographic: "1" < "5")
"10" < 5;           // false ("10" -> 10, 10 < 5 is false)
[1] < [2];          // true ([1] -> "1" -> 1, [2] -> "2" -> 2)
{} < {};            // false ({} -> NaN, NaN < NaN is false)

Gotcha: String comparison is lexicographic, not numeric:

"10" < "2";         // true ("1" < "2")
10 < 2;             // false

Systems note: If you’re generating comparison code, ensure operands are the same type to avoid coercion surprises.

Autoboxing: Primitives with Methods

The Illusion of Primitive Methods

Primitives (String, Number, Boolean, Symbol, BigInt) are not objects. Yet you can call methods on them:

"hello".toUpperCase();  // "HELLO"
(42).toFixed(2);        // "42.00"
true.toString();        // "true"

How? Autoboxing (also called wrapping). When you access a property on a primitive, JavaScript temporarily converts it to an object:

Algorithm (§7.1.19, p. 72):

ToObject ( argument )

1. If argument is undefined or null, throw TypeError.

2. If argument is a Boolean, return a Boolean object wrapping argument.

3. If argument is a Number, return a Number object wrapping argument.

4. If argument is a String, return a String object wrapping argument.

5. If argument is a Symbol, return a Symbol object wrapping argument.

6. If argument is a BigInt, return a BigInt object wrapping argument.

7. If argument is an Object, return argument.

Example:

const str = "hello";
str.toUpperCase();  // Internally: ToObject(str).toUpperCase()

The wrapper object is created, the method is called, and the wrapper is discarded.

Wrapper constructors:

const strObj = new String("hello");
console.log(typeof strObj);       // "object"
console.log(strObj.valueOf());    // "hello" (unwrap)
console.log(strObj === "hello");  // false (object vs. primitive)

Never use wrapper constructors explicitly (with new). They’re confusing and unnecessary. If you want to convert types, call without new:

String(42);   // "42" (converts to primitive string)
Number("42"); // 42 (converts to primitive number)

Why Autoboxing Matters

Performance: Autoboxing has overhead. Engines optimize it (e.g., V8 inlines wrapper creation), but it’s still slower than operating on primitives directly.

Mutation doesn’t work:

const str = "hello";
str.foo = "bar";
console.log(str.foo); // undefined (the wrapper is discarded)

Each access creates a new wrapper, so assignments are lost.

Systems note: If you’re compiling to JavaScript and want to attach metadata to primitives, you can’t. You’ll need to use a Map or WeakMap to associate data with primitives.

Value vs. Reference Semantics: The Great Divide

Primitives Are Passed by Value

When you assign a primitive to a variable or pass it to a function, the value is copied:

let a = 5;
let b = a;
b = 10;
console.log(a); // 5 (unchanged)

function modify(x) {
    x = 100;
}
let num = 50;
modify(num);
console.log(num); // 50 (unchanged)

Systems analogy: Primitives behave like C’s int, double, etc.—pass-by-value.

Objects Are Passed by Reference

When you assign an object to a variable or pass it to a function, the reference is copied, not the object itself:

let obj1 = { x: 5 };
let obj2 = obj1;
obj2.x = 10;
console.log(obj1.x); // 10 (mutated!)

function modify(obj) {
    obj.x = 100;
}
let myObj = { x: 50 };
modify(myObj);
console.log(myObj.x); // 100 (mutated!)

But reassigning the variable doesn’t affect the original:

function modify(obj) {
    obj = { x: 200 };
}
let myObj = { x: 50 };
modify(myObj);
console.log(myObj.x); // 50 (unchanged, because we reassigned the local variable)

Systems analogy: Objects behave like C pointers—you’re passing the address, not the data. Mutating through the pointer affects the original. Reassigning the pointer doesn’t.

Implications for Transpiler Design

If you’re compiling a language with value semantics (like Rust or C++ structs) to JavaScript:

• Option 1: Represent structs as objects, but deep clone on assignment (expensive).

• Option 2: Use immutable patterns (return new objects instead of mutating).

• Option 3: Use Object.freeze() to prevent mutation (throws errors in strict mode).

Example (deep clone):

function cloneStruct(obj) {
    return JSON.parse(JSON.stringify(obj)); // Naive, doesn't handle functions/symbols
}

let struct1 = { x: 5, y: 10 };
let struct2 = cloneStruct(struct1);
struct2.x = 20;
console.log(struct1.x); // 5 (unchanged)

Better cloning (structured clone, ES2022):

let struct2 = structuredClone(struct1);

Shallow vs. Deep Comparison

=== compares references for objects:

console.log({} === {});       // false (different references)
console.log([] === []);       // false
let obj = {};
console.log(obj === obj);     // true (same reference)

Deep comparison requires a custom function:

function deepEqual(a, b) {
    if (a === b) return true;
    if (typeof a !== "object" || typeof b !== "object") return false;
    if (a === null || b === null) return false;
    
    const keysA = Object.keys(a);
    const keysB = Object.keys(b);
    if (keysA.length !== keysB.length) return false;
    
    for (const key of keysA) {
        if (!keysB.includes(key)) return false;
        if (!deepEqual(a[key], b[key])) return false;
    }
    return true;
}

console.log(deepEqual({ x: 1 }, { x: 1 })); // true
console.log(deepEqual([1, 2], [1, 2]));     // true

Systems note: If you’re emitting comparison code, primitives can use ===, but objects require deep comparison if you want value semantics.

Memory Management: Garbage Collection and WeakMaps

JavaScript Has Automatic Garbage Collection

Unlike C, you don’t manually allocate/free memory. JavaScript engines use tracing garbage collectors (mark-and-sweep or generational GC).

Key insight: You can’t deallocate memory explicitly. Objects are collected when unreachable.

Example:

let obj = { data: "large array" };
obj = null; // Now the object is unreachable and can be GC'd

Generational GC (V8)

V8 uses a generational garbage collector with two generations:

1. Young generation (nursery): New objects. GC’d frequently (minor GC, fast).

2. Old generation (tenured): Objects that survive multiple young-gen GCs. GC’d infrequently (major GC, slow).

Promotion: Objects move from young to old after surviving several collections.

Stop-the-world pauses: GC pauses JavaScript execution. V8 uses incremental marking and concurrent sweeping to minimize pauses.

Memory Leaks in JavaScript

You can’t have use-after-free or double-free bugs (GC prevents that), but you can have memory leaks—objects that are reachable but no longer needed.

Common causes:

1. Global variables: Never collected.

2. Closures: Capture variables in scope, preventing collection.

3. Event listeners: Not removed when DOM elements are removed.

4. Caches without eviction: Map or object holding references indefinitely.

Example (closure leak):

function createLeakyFunction() {
    const largeData = new Array(1000000).fill("data");
    return function() {
        console.log("I capture largeData in my closure!");
    };
}

const fn = createLeakyFunction(); // largeData is retained

Even if you never use largeData in the returned function, it’s captured in the closure’s scope.

WeakMap and WeakSet: Weak References

Specification: §25.3 (WeakMap, pp. 651-656), §25.4 (WeakSet, pp. 657-660)

WeakMap and WeakSet hold weak references to keys. If the only reference to a key is from a WeakMap/WeakSet, the key can be garbage collected.

Use case: Associating metadata with objects without preventing their collection.

Example:

const metadata = new WeakMap();

let obj = { id: 1 };
metadata.set(obj, { timestamp: Date.now() });

console.log(metadata.get(obj)); // { timestamp: ... }

obj = null; // Now obj can be GC'd, and the WeakMap entry is removed

Contrast with Map:

const metadata = new Map();

let obj = { id: 1 };
metadata.set(obj, { timestamp: Date.now() });

obj = null; // obj is still reachable via the Map, so it's NOT GC'd

WeakRef (ES2021): For even finer control, WeakRef creates a weak reference to an object. You can check if it’s still alive:

let obj = { data: "important" };
const ref = new WeakRef(obj);

console.log(ref.deref()); // { data: "important" }

obj = null; // Object may be GC'd

setTimeout(() => {
    console.log(ref.deref()); // undefined (if GC'd)
}, 1000);

FinalizationRegistry (ES2021): Runs a callback when an object is collected:

const registry = new FinalizationRegistry((heldValue) => {
    console.log(`Object with value ${heldValue} was collected`);
});

let obj = { id: 1 };
registry.register(obj, "myObject");

obj = null; // Callback runs eventually after GC

Systems note: If you’re implementing a transpiler with manual memory management (e.g., compiling C to JavaScript), you can use WeakMap to associate metadata (like allocation info) with objects without preventing collection.

Specification Types: Internal Constructs You’ll Never Touch Directly

What Are Specification Types?

In addition to the seven language types (Undefined, Null, Boolean, String, Symbol, Number, BigInt, Object), the spec defines specification types—internal constructs used in algorithmic descriptions. These are not accessible in JavaScript code.

Specification types (§6.2, pp. 43-61):

1. Completion Record: Represents the result of an operation (normal, return, throw, break, continue).

2. Reference: Represents a binding (variable, property).

3. Property Descriptor: Describes a property’s attributes.

4. Environment Record: Stores variable bindings (lexical scope).

5. Data Block: Raw binary data (for TypedArrays, SharedArrayBuffer).

Completion Record: How Control Flow Works Internally

Specification: §6.2.3 (pp. 44-45)

Every abstract operation returns a Completion Record:

CompletionRecord { [[Type]]: normal | return | throw | break | continue [[Value]]: any value [[Target]]: label (for break/continue) }

Normal completion: Operation succeeded, [[Value]] is the result.

Abrupt completion: Operation failed or control flow changed (return, throw, break, continue).

The ? operator (§5.2.3.3, p. 15):

Let result be ? SomeOperation().

Equivalent to:

Let result be SomeOperation(). If result is an abrupt completion, return result. Otherwise, let result be result.[[Value]].

The ! operator (§5.2.3.4, p. 15):

Let result be ! SomeOperation().

Equivalent to:

Let result be SomeOperation(). Assert: result is a normal completion. Let result be result.[[Value]].

Systems analogy: Completion Records are like error codes in C (-1 for error, 0 for success) or Rust’s Result<T, E>. The ? operator is like Rust’s ? operator (early return on error).

Reference: How Variable Lookup Works

Specification: §6.2.4 (pp. 45-46)

A Reference represents a binding to a variable or property:

Reference { [[Base]]: environment record or object [[ReferencedName]]: property key or variable name [[Strict]]: boolean (strict mode?) }

Example: In obj.prop, the reference is:

Reference { [[Base]]: obj [[ReferencedName]]: “prop” }

GetValue (§6.2.4.5, p. 46) dereferences the reference:

GetValue ( V )

1. If V is not a Reference, return V.

2. Let base be V.[[Base]].

3. If base is an Environment Record, return base.GetBindingValue(V.[[ReferencedName]]).

4. Else (base is an Object),

   1. Return ? base.[Get].

Systems note: This is how a.b is evaluated—the parser creates a Reference, and runtime dereferences it.

Property Descriptor: How Properties Are Stored

Specification: §6.2.5 (pp. 46-47)

A Property Descriptor describes a property’s attributes:

PropertyDescriptor { [[Value]]: any (for data properties) [[Writable]]: boolean (for data properties) [[Get]]: function (for accessor properties) [[Set]]: function (for accessor properties) [[Enumerable]]: boolean [[Configurable]]: boolean }

Data property:

const obj = {};
Object.defineProperty(obj, "x", {
    value: 42,
    writable: true,
    enumerable: true,
    configurable: true
});

Accessor property:

const obj = {};
Object.defineProperty(obj, "x", {
    get() { return this._x; },
    set(val) { this._x = val; },
    enumerable: true,
    configurable: true
});

Systems note: If you’re implementing object property access in a transpiler, you need to handle both data and accessor properties correctly.

Environment Record: Lexical Scope

Specification: §9.1 (pp. 137-145)

An Environment Record stores variable bindings for a scope:

EnvironmentRecord { [[OuterEnv]]: parent environment (for scope chain) bindings: map of variable names to values }

Three kinds:

1. Declarative Environment Record: let, const, function parameters.

2. Object Environment Record: with statement (legacy), global object.

3. Global Environment Record: Global scope (combines declarative and object).

Lexical scope is implemented as a linked list of environment records:

Global Environment

-> Function Environment (outer function)

-> Block Environment (let/const in block)

Systems analogy: Environment Records are like stack frames in C, but heap-allocated (for closures). The [[OuterEnv]] pointer is like the frame pointer linking to the caller’s frame.

End of Chapter 2

In the next chapter, we’ll explore JavaScript’s object model in depth—prototypes, inheritance, property access, the this keyword, and how engines optimize object layout with hidden classes.

Chapter 3: The Execution Model: Event Loop, Call Stack, and Heap

JavaScript’s Single-Threaded Concurrency Model

The Fundamental Constraint: One Thread of Execution

JavaScript was designed for the browser. In 1995, Netscape wanted a simple scripting language that could manipulate HTML without the complexity of threads. Brendan Eich’s solution: a single-threaded execution model with asynchronous I/O.

What does “single-threaded” mean?

• Only one JavaScript call stack at a time.

• Only one statement executes at any given moment.

• No race conditions on shared memory (in the traditional sense).

• No need for locks, mutexes, or semaphores in JavaScript code.

Systems analogy: Contrast this with POSIX threads (pthreads) in C:

pthread_t thread1, thread2;
int shared_counter = 0;
pthread_mutex_t lock;

void* increment(void* arg) {
    pthread_mutex_lock(&lock);
    shared_counter++;
    pthread_mutex_unlock(&lock);
    return NULL;
}

pthread_create(&thread1, NULL, increment, NULL);
pthread_create(&thread2, NULL, increment, NULL);

In JavaScript, you never write code like this. The single-threaded model eliminates the need for explicit synchronization primitives at the language level.

But how does JavaScript handle I/O without blocking?

The answer is the event loop—a run-to-completion model where asynchronous operations are queued and executed when the stack is empty.

The Event Loop Architecture: A Conceptual Overview

The JavaScript runtime consists of three core components:

1. Call Stack: Tracks function execution (stack frames).

2. Heap: Stores objects and closures (garbage-collected memory).

3. Event Loop: Coordinates asynchronous tasks (timers, I/O, promises).

Diagram (conceptual):

┌│─────────────────────────────────────────────────────────┐

││ JavaScript Runtime │

├│─────────────────────────────────────────────────────────┤

││ │

││ ┌──────────────┐ ┌──────────────┐ │

││ │ Call Stack │ │ Heap │ │

││ │ │ │ │ │

││ │ frame_n │ │ Object@0x1 │ │

││ │ frame_n-1 │ │ Object@0x2 │ │

││ │ … │ │ … │ │

││ │ frame_0 │ │ │ │

││ └──────────────┘ └──────────────┘ │

││ │

││ ┌─────────────────────────────────────────────────┐ │

││ │ Event Loop (Message Queue) │ │

││ ├─────────────────────────────────────────────────┤ │

││ │ Task Queue (Macrotasks): │ │

││ │ [setTimeout, setInterval, I/O, UI events] │ │

││ │ Microtask Queue: │ │

││ │ [Promise callbacks, queueMicrotask] │ │

││ └─────────────────────────────────────────────────┘ │

││ │ └─────────────────────────────────────────────────────────┘ ▲ │ Web APIs / Node.js APIs (setTimeout, fetch, fs.readFile, etc.)

Execution flow:

1. Synchronous code runs on the call stack until completion.

2. Asynchronous operations (timers, I/O) are delegated to Web APIs (browser) or libuv (Node.js).

3. When an async operation completes, its callback is enqueued.

4. The event loop dequeues tasks when the call stack is empty.

Key invariant: The event loop never interrupts executing code. Each task runs to completion before the next task starts.

The Event Loop Specification (HTML Living Standard)

JavaScript’s core spec (ECMA-262) does not define the event loop. It’s defined in:

• Browser: HTML Living Standard, Section 8.1.6 (Event Loops)

• Node.js: libuv documentation

ECMA-262’s Job Queue (§9.5, pp. 150-151):

The spec defines an abstract job queue for promise reactions (microtasks), but leaves the event loop implementation-defined:

Jobs are scheduled for future execution via EnqueueJob. The Host (browser or Node.js) determines when jobs are executed.

HTML Living Standard’s Event Loop:

Each event loop has:

• Task queues (plural): Multiple queues for different task sources (timers, I/O, rendering).

• Microtask queue: Single queue for promise callbacks.

• Rendering pipeline: Steps for updating the DOM and screen.

Node.js’s Event Loop:

Six phases, each with a queue:

1. Timers: setTimeout, setInterval.

2. Pending callbacks: I/O callbacks deferred from the previous cycle.

3. Idle, prepare: Internal use.

4. Poll: Retrieve new I/O events; execute I/O callbacks.

5. Check: setImmediate callbacks.

6. Close callbacks: socket.on('close', ...).

Between each phase, the microtask queue is drained.

Systems takeaway: The event loop is host-defined, but the core principle is the same: run to completion + task queues.

The Call Stack: Execution Contexts and Stack Frames

Execution Contexts: The Spec’s Abstraction

Specification: §9.4 (pp. 146-150)

An execution context is the spec’s abstraction for “what’s currently executing.” It contains:

ExecutionContext { CodeEvaluationState: suspend/resume (for generators/async) Function: the function being executed (or null for global/eval) Realm: the global object and intrinsics ScriptOrModule: the script or module LexicalEnvironment: current lexical scope (let/const) VariableEnvironment: current variable scope (var) PrivateEnvironment: private fields (class fields) }

Execution context stack: A stack of execution contexts (analogous to the call stack in C).

Example:

function outer() {
    let x = 1;
    function inner() {
        let y = 2;
        console.log(x + y);
    }
    inner();
}
outer();

Execution context stack evolution:

Initial: [GlobalExecutionContext]

outer() called: [GlobalExecutionContext, outer_ExecutionContext]

inner() called: [GlobalExecutionContext, outer_ExecutionContext, inner_ExecutionContext]

inner() returns: [GlobalExecutionContext, outer_ExecutionContext]

outer() returns: [GlobalExecutionContext]

Systems analogy: This is identical to the call stack in C:

void inner() { int y = 2; printf("%d\n", y); }
void outer() { int x = 1; inner(); }
void main() { outer(); }

Call stack:

main’s frame

-> outer’s frame

-> inner's frame

Stack Frames in JavaScript Engines

Engines don’t literally implement the spec’s execution context stack—they use optimized stack frames (like C compilers).

V8’s stack frame (simplified):

┌│─────────────────────────────────────┐

││ Return Address (caller’s PC) │

││ Frame Pointer (FP, points to base) │

││ Context (pointer to lexical env) │

││ Function (pointer to JSFunction) │

││ Receiver (this) │

││ Argument 0 │

││ Argument 1 │

││ … │

││ Local Variable 0 │

││ Local Variable 1 │

││ … │

││ Temporary Value 0 (stack operands) │

││ Temporary Value 1 │

││ … │ └─────────────────────────────────────┘

Key elements:

• Return address: Where to jump after the function returns.

• Frame pointer (FP): Base of the current frame (like rbp in x86-64).

• Context: Pointer to the LexicalEnvironment (for closures).

• Receiver: The this value.

• Arguments: Function parameters.

• Locals: Local variables.

• Temporaries: Operands for bytecode instructions.

Systems note: JavaScript’s stack frames are heap-allocated if the function creates a closure (the context must outlive the function). Otherwise, they’re stack-allocated.

Stack Overflow: Recursion Depth Limits

JavaScript has a maximum call stack size (implementation-defined). Exceeding it throws RangeError: Maximum call stack size exceeded.

Example:

function recurse() {
    recurse(); // Infinite recursion
}
recurse(); // RangeError

Stack size limits (typical):

• V8 (Chrome/Node.js): ~10,000-15,000 frames (depends on platform).

• SpiderMonkey (Firefox): ~50,000 frames.

• JavaScriptCore (Safari): ~100,000 frames.

Systems implication: If you’re compiling a recursive language (Scheme, Haskell) to JavaScript, you need tail call optimization (TCO) or trampolining.

Tail Call Optimization (TCO): ES6 specified TCO in strict mode (§15.9.1, p. 361), but only Safari implements it. V8 and SpiderMonkey explicitly rejected it due to debugger complexity.

Trampolining: Convert recursion to iteration:

function trampoline(fn) {
    let result = fn();
    while (typeof result === "function") {
        result = result();
    }
    return result;
}

function factorial(n, acc = 1) {
    if (n <= 1) return acc;
    return () => factorial(n - 1, n * acc); // Return a thunk
}

console.log(trampoline(() => factorial(100000))); // Works!

Continuation-Passing Style (CPS): Another approach—pass the “rest of the computation” as a callback:

function factorial_cps(n, k) {
    if (n <= 1) return k(1);
    return factorial_cps(n - 1, (result) => k(n * result));
}

factorial_cps(5, (result) => console.log(result)); // 120

But this still overflows without TCO. You’d need to trampoline the CPS’d function.

Stack Traces and Debugging

Error.stack (non-standard but universal):

function foo() { bar(); }
function bar() { baz(); }
function baz() { console.log(new Error().stack); }
foo();

Output (V8):

Error at baz (:3:29) at bar (:2:14) at foo (:1:14) at :4:1

Source maps: For transpiled/minified code, engines use source maps (.map files) to map stack traces back to original source.

Systems note: If you’re building a transpiler, generate source maps (§13.5) so stack traces are useful.

The Heap: Object Storage and Garbage Collection

Heap Layout: Young Gen, Old Gen, Large Objects

JavaScript engines use generational garbage collection with multiple heap regions:

V8’s heap structure:

┌│─────────────────────────────────────────────────────┐

││ V8 Heap │

├│─────────────────────────────────────────────────────┤

││ Young Generation (Scavenger, Semi-Space) │

││ - From-space (active) │

││ - To-space (evacuation target) │

││ - Typical size: 1-8 MB │

││ - GC frequency: Very frequent (minor GC) │

├│─────────────────────────────────────────────────────┤

││ Old Generation (Mark-Sweep-Compact) │

││ - Old pointer space (objects with pointers) │

││ - Old data space (objects without pointers) │

││ - Typical size: 100s of MB │

││ - GC frequency: Infrequent (major GC) │

├│─────────────────────────────────────────────────────┤

││ Large Object Space │

││ - Objects > 64 KB (in V8) │

││ - Never moved (to avoid copying overhead) │

├│─────────────────────────────────────────────────────┤

││ Code Space │

││ - Compiled machine code (JIT’d functions) │

││ - Executable memory (W^X protection) │ └─────────────────────────────────────────────────────┘

Young generation (nursery):

• New objects are allocated here.

• Minor GC (Scavenger): Runs frequently (~1-10 ms pause).

• Copying collector: Evacuates live objects to to-space, then swaps spaces.

• Survival: Objects that survive 2-3 minor GCs are promoted to old gen.

Old generation:

• Long-lived objects.

• Major GC (Mark-Sweep-Compact): Runs infrequently (~100-1000 ms pause).

• Tri-color marking: Incremental marking to reduce pauses.

• Compaction: Periodically compacts memory to reduce fragmentation.

Large object space:

• Objects too large to fit in young/old gen (e.g., large arrays, buffers).

• Never moved (to avoid copying cost).

Systems analogy: Similar to multi-generational GC in JVM (Hotspot), GHC (Haskell), or .NET CLR.

Garbage Collection Algorithms

Minor GC: Cheney’s Semi-Space Collector

Algorithm:

1. Divide young gen into two equal semi-spaces: from-space and to-space.

2. Allocate objects in from-space (bump-pointer allocation, very fast).

3. When from-space is full, evacuate live objects to to-space:

   • Start from roots (global objects, stack, registers).

   • Traverse the object graph (BFS or DFS).

   • Copy each reachable object to to-space.

   • Update pointers to point to the new location.

4. Swap from-space and to-space.

5. Dead objects are implicitly reclaimed (left in the old from-space).

Complexity:

• Time: $O(L)$ where $L$ is the number of live objects (dead objects are ignored).

• Space: Wastes 50% of young gen (to-space is empty until GC).

Why so fast? Most objects die young (the generational hypothesis). Copying only live objects is faster than marking all objects.

Systems note: This is the same algorithm used in early LISP systems (Cheney 1970).

Major GC: Mark-Sweep-Compact

Mark phase:

1. Start from roots.

2. Mark reachable objects (set a bit in the object header or a bitmap).

3. Use tri-color marking for incrementality:

   • White: Unvisited.

   • Gray: Visited, but children not yet scanned.

   • Black: Visited, children scanned.

Sweep phase:

1. Scan the entire old gen.

2. Add unmarked objects to the free list.

3. Reset mark bits.

Compact phase (optional, periodic):

1. Move objects to eliminate fragmentation.

2. Update all pointers.

Incremental marking: V8 splits the mark phase into small steps (1-5 ms each), interleaved with JavaScript execution. This reduces pause times.

Concurrent marking/sweeping: V8 uses parallel threads to mark/sweep concurrently with JavaScript execution (requires write barriers to track pointer updates).

Systems analogy: Similar to mark-sweep in Boehm GC (C/C++) or concurrent mark-sweep in JVM G1GC.

Write Barriers: Tracking Pointer Updates

Problem: If the GC runs incrementally, JavaScript code might update pointers while marking is in progress. The GC must track these updates to avoid missing live objects.

Solution: Write barriers—instrumentation inserted by the compiler to track pointer writes.

Example (pseudo-code):

// Without write barrier:
obj.field = newValue;

// With write barrier:
obj.field = newValue;
if (isMarking && isBlack(obj) && isWhite(newValue)) {
    markGray(newValue); // Prevent missing this object
}

V8’s write barrier:

; Store newValue to obj.field
mov [obj + field_offset], newValue
; Write barrier check
test [marking_flag], 1
jz skip_barrier
call WriteBarrier
skip_barrier:

Cost: Write barriers add overhead to every pointer write (~5-10% slowdown). But they enable concurrent GC, which reduces pauses.

Systems note: If you’re compiling to WebAssembly and want GC, you’ll need to implement write barriers yourself (WebAssembly GC proposal will add native support).

Memory Leaks: Common Pitfalls

Even with GC, you can leak memory by keeping objects reachable when they’re no longer needed.

Pitfall 1: Accidental Global Variables

function leak() {
    leakyVariable = "This is a global!"; // Forgot 'let', becomes global
}
leak();

Fix: Use strict mode ("use strict";), which throws ReferenceError for undeclared variables.

Pitfall 2: Closures Capturing Large Scopes

function createLeakyFunction() {
    const largeArray = new Array(1000000).fill("data");
    const smallValue = 42;
    
    return function() {
        console.log(smallValue); // Only uses smallValue
    };
}

const fn = createLeakyFunction(); // But largeArray is retained!

Why? JavaScript closures capture the entire lexical environment, not just the variables they reference.

Fix (manual scope minimization):

function createLeakyFunction() {
    const largeArray = new Array(1000000).fill("data");
    const smallValue = 42;
    
    // Process largeArray here, then discard
    // ...
    
    return function() {
        console.log(smallValue); // Now only smallValue is captured
    };
}

V8 optimization: Modern engines analyze closures and only capture used variables. But this isn’t guaranteed.

Pitfall 3: Event Listeners Not Removed

const element = document.getElementById("myButton");
const handler = () => console.log("Clicked!");

element.addEventListener("click", handler);

// Later, remove the element from DOM:
element.remove();
// But the listener is still registered! Memory leak.

Fix: Remove listeners explicitly:

element.removeEventListener("click", handler);

Or use { once: true }:

element.addEventListener("click", handler, { once: true });

Pitfall 4: Caches Without Eviction

const cache = {};

function getCachedData(key) {
    if (!(key in cache)) {
        cache[key] = expensiveComputation(key);
    }
    return cache[key];
}

Problem: cache grows unbounded.

Fix: Use Map with size limits, or WeakMap (if keys are objects):

const cache = new WeakMap();

function getCachedData(obj) {
    if (!cache.has(obj)) {
        cache.set(obj, expensiveComputation(obj));
    }
    return cache.get(obj);
}

// If obj is no longer reachable, the cache entry is GC'd

Profiling Heap Usage

Chrome DevTools:

1. Open DevTools → Memory tab.

2. Take a heap snapshot.

3. Analyze object retainers (why an object is still alive).

Node.js:

const v8 = require("v8");
const heapStats = v8.getHeapStatistics();
console.log(heapStats);

Output:

{
  total_heap_size: 7376896,
  used_heap_size: 4523432,
  heap_size_limit: 2197815296,
  // ...
}

Memory snapshots:

const v8 = require("v8");
const fs = require("fs");

const snapshot = v8.writeHeapSnapshot();
console.log(`Snapshot written to ${snapshot}`);

Open the .heapsnapshot file in Chrome DevTools for analysis.

The Event Loop: Task Queues and Microtasks

Macrotasks vs. Microtasks

JavaScript has two types of asynchronous tasks:

1. Macrotasks (Tasks): setTimeout, setInterval, I/O, UI events.

2. Microtasks (Jobs): Promise callbacks (then, catch, finally), queueMicrotask(), MutationObserver.

Execution order:

1. Execute one macrotask from the task queue.

2. Execute ALL microtasks from the microtask queue.

3. Render (if browser, and if necessary).

4. Repeat.

Key difference: Microtasks interrupt macrotasks. After each macrotask, the microtask queue is drained before the next macrotask.

Example:

console.log("Script start");

setTimeout(() => console.log("setTimeout"), 0);

Promise.resolve()
    .then(() => console.log("Promise 1"))
    .then(() => console.log("Promise 2"));

console.log("Script end");

Output:

Script start Script end Promise 1 Promise 2 setTimeout

Explanation:

1. Synchronous code: "Script start", "Script end".

2. Microtasks: "Promise 1", "Promise 2".

3. Macrotask: "setTimeout".

Systems analogy: Microtasks are like interrupt handlers—they run before the next task. Macrotasks are like scheduled jobs.

Task Queue: Macrotask Sources

Browser:

• setTimeout/setInterval: Timers.

• I/O: fetch(), XMLHttpRequest.

• UI events: click, keydown, etc.

• Rendering: requestAnimationFrame.

Node.js:

• Timers: setTimeout, setInterval.

• I/O: fs.readFile, net.connect.

• Immediate: setImmediate (runs after I/O, before timers).

• Close callbacks: socket.on('close').

Task ordering: The spec does not guarantee FIFO order for tasks from different sources. In practice, each task source has its own queue, and the event loop selects from them in implementation-defined order.

Microtask Queue: Promise Callbacks

HTML spec: After each task, the event loop performs a microtask checkpoint:

Microtask Checkpoint

1. If the microtask queue is empty, return.

2. Let oldestMicrotask be the first microtask in the queue.

3. Remove oldestMicrotask from the queue.

4. Run oldestMicrotask.

5. Goto step 1 (repeat until queue is empty).

ECMA-262 spec: §9.5.4 (p. 151) defines PerformPromiseJob (equivalent to microtask execution).

Example (nested promises):

Promise.resolve().then(() => {
    console.log("1");
    Promise.resolve().then(() => console.log("2"));
});
Promise.resolve().then(() => console.log("3"));

Output:

1 3 2

Explanation:

1. First then callback: console.log("1"), enqueues "2".

2. Second then callback: console.log("3").

3. Nested then callback: console.log("2").

Microtask starvation: If a microtask keeps enqueuing more microtasks, the event loop never advances to the next macrotask:

function recursiveMicrotask() {
    queueMicrotask(recursiveMicrotask);
}
recursiveMicrotask();
// Infinite loop! No macrotasks (timers, I/O) will ever run.

Systems lesson: Microtasks can starve macrotasks. Use with caution.

queueMicrotask(): Manual Microtask Scheduling

Specification: HTML Living Standard, Section 8.5.2

API:

queueMicrotask(callback);

Example:

console.log("Start");

queueMicrotask(() => console.log("Microtask"));

console.log("End");

Output:

Start End Microtask

Use case: Batching updates:

let updates = [];

function scheduleUpdate(data) {
    updates.push(data);
    if (updates.length === 1) {
        queueMicrotask(() => {
            flushUpdates();
            updates = [];
        });
    }
}

function flushUpdates() {
    console.log("Flushing:", updates);
}

scheduleUpdate("A");
scheduleUpdate("B");
scheduleUpdate("C");
// Output: Flushing: ["A", "B", "C"]

Node.js Event Loop: Six Phases

Node.js event loop (libuv):

┌───────────────────────────┐

┌│─>│ timers │ (setTimeout, setInterval)

││ └─────────────┬─────────────┘

││ ┌─────────────┴─────────────┐

││ │ pending callbacks │ (I/O callbacks deferred from prev cycle)

││ └─────────────┬─────────────┘

││ ┌─────────────┴─────────────┐

││ │ idle, prepare │ (internal)

││ └─────────────┬─────────────┘ ┌───────────────┐

││ ┌─────────────┴─────────────┐ │ incoming: │

││ │ poll │<─────┤ connections, │

││ └─────────────┬─────────────┘ │ data, etc. │

││ ┌─────────────┴─────────────┐ └───────────────┘

││ │ check │ (setImmediate)

││ └─────────────┬─────────────┘

││ ┌─────────────┴─────────────┐ └──┤ close callbacks │ (e.g., socket.on(‘close’)) └───────────────────────────┘

Between each phase: Microtask queue is drained.

Timers phase:

setTimeout(() => console.log("Timer 1"), 0);
setTimeout(() => console.log("Timer 2"), 0);
// Both run in the timers phase, in order.

Poll phase:

• Wait for I/O events (with a timeout).

• Execute I/O callbacks.

• If no timers and no setImmediate, block until I/O arrives.

Check phase (setImmediate):

setImmediate(() => console.log("Immediate"));

Runs after the poll phase, even if scheduled in the same iteration.

Close callbacks phase:

const socket = new net.Socket();
socket.on("close", () => console.log("Socket closed"));
socket.destroy();

process.nextTick(): The Hidden Microtask Queue

Node.js-specific: process.nextTick() schedules a callback to run before the event loop continues to the next phase.

Execution order:

1. Run the current phase’s callbacks.

2. Execute ALL process.nextTick callbacks.

3. Execute ALL promise microtasks.

4. Move to the next phase.

Example:

console.log("Start");

setTimeout(() => console.log("setTimeout"), 0);
setImmediate(() => console.log("setImmediate"));

process.nextTick(() => console.log("nextTick 1"));
Promise.resolve().then(() => console.log("Promise"));
process.nextTick(() => console.log("nextTick 2"));

console.log("End");

Output (Node.js):

Start End nextTick 1 nextTick 2 Promise setTimeout setImmediate

Why nextTick before promises? Node.js’s nextTick queue is processed before the microtask queue. This is a Node.js-specific quirk.

Warning: process.nextTick can starve the event loop:

function recursiveNextTick() {
    process.nextTick(recursiveNextTick);
}
recursiveNextTick();
// Infinite loop! Event loop phases never advance.

Systems lesson: Prefer queueMicrotask() or promises for portability. Only use process.nextTick() when you explicitly need to run before microtasks (rare).

Timers: setTimeout, setInterval, and Precision

setTimeout: Single-Shot Timer

Specification: HTML Living Standard, Section 8.6

API:

const timerId = setTimeout(callback, delay, ...args);
clearTimeout(timerId);

Example:

setTimeout(() => console.log("Hello"), 1000);

Key points:

1. Minimum delay: Browsers clamp delays < 4ms to 4ms (if nested > 5 levels). Node.js has no minimum (0ms is allowed).

2. Not guaranteed: The callback runs at least delay milliseconds later, but may be delayed by:

   • Long-running tasks on the call stack.

   • Other tasks in the queue.

3. Passed arguments: After delay, you can pass arguments to the callback:

setTimeout((a, b) => console.log(a + b), 1000, 5, 10); // Logs 15 after 1s

Canceling a timer:

const id = setTimeout(() => console.log("Never runs"), 1000);
clearTimeout(id);

setInterval: Repeating Timer

API:

const intervalId = setInterval(callback, delay, ...args);
clearInterval(intervalId);

Example:

let count = 0;
const id = setInterval(() => {
    console.log(++count);
    if (count === 5) clearInterval(id);
}, 1000);

Pitfall: Interval drift: If the callback takes longer than delay, intervals can overlap or drift.

Example:

setInterval(() => {
    const start = Date.now();
    while (Date.now() - start < 100) {} // Simulate 100ms work
    console.log("Done");
}, 50); // Scheduled every 50ms, but takes 100ms

Output: “Done” every ~100ms, not 50ms.

Fix: Use setTimeout recursively:

function repeat() {
    console.log("Done");
    setTimeout(repeat, 50);
}
repeat();

Now each invocation is scheduled after the previous one completes.

Timer Precision: The Reality Check

JavaScript timers are not precise. The delay is a minimum, not a guarantee.

Example:

const start = Date.now();
setTimeout(() => {
    console.log(`Elapsed: ${Date.now() - start}ms`);
}, 1000);

Output: Typically 1000-1005ms, but can be 1050ms or more if the system is busy.

Why?

1. Event loop: Timers are checked at the start of each event loop iteration. If the loop is blocked, timers are delayed.

2. OS scheduler: The OS may not wake the process exactly when the timer expires.

3. Browser throttling: Background tabs throttle timers to 1-second intervals (to save battery).

High-precision timers (performance.now()):

const start = performance.now();
setTimeout(() => {
    const elapsed = performance.now() - start;
    console.log(`Elapsed: ${elapsed}ms`);
}, 1000);

Output: More precise (microsecond resolution), but still subject to event loop delays.

Systems note: If you need precise timing (e.g., for animation), use requestAnimationFrame() (browser) or high-resolution timers (Node.js process.hrtime()).

Promises and Async/Await: Syntactic Sugar Over the Event Loop

Promises: Microtask-Based Asynchrony

Specification: §27.2 (pp. 673-706)

Promise states (§27.2.1.1, p. 674):

• Pending: Initial state.

• Fulfilled: Operation completed successfully.

• Rejected: Operation failed.

State transitions:

pending → fulfilled (resolve) pending → rejected (reject)

Once fulfilled or rejected, a promise is settled (immutable).

Creating a promise:

const promise = new Promise((resolve, reject) => {
    setTimeout(() => {
        if (Math.random() > 0.5) {
            resolve("Success!");
        } else {
            reject(new Error("Failure!"));
        }
    }, 1000);
});

promise
    .then(result => console.log(result))
    .catch(error => console.error(error));

Chaining:

Promise.resolve(5)
    .then(x => x * 2)
    .then(x => x + 3)
    .then(x => console.log(x)); // 13

Each then returns a new promise, allowing chains.

Async/Await: State Machine Compilation

Specification: §15.8 (pp. 346-354)

async/await is syntactic sugar for promises. The compiler transforms it into a state machine.

Example:

async function fetchData() {
    const response = await fetch("https://api.example.com/data");
    const data = await response.json();
    return data;
}

Desugared (conceptual):

function fetchData() {
    return new Promise((resolve, reject) => {
        fetch("https://api.example.com/data")
            .then(response => response.json())
            .then(data => resolve(data))
            .catch(error => reject(error));
    });
}

Actually, the compiler generates a state machine (similar to generators):

function fetchData() {
    let state = 0;
    let response, data;

    function step(value) {
        switch (state) {
            case 0:
                state = 1;
                return fetch("https://api.example.com/data");
            case 1:
                response = value;
                state = 2;
                return response.json();
            case 2:
                data = value;
                return data;
        }
    }

    return new Promise((resolve, reject) => {
        function next(value) {
            const result = step(value);
            if (result instanceof Promise) {
                result.then(next, reject);
            } else {
                resolve(result);
            }
        }
        next();
    });
}

Systems analogy: Async functions are compiled to coroutines with explicit state. The await keyword is a suspension point—execution pauses, the promise is awaited, and execution resumes when the promise settles.

Error Handling: try/catch in Async Functions

async function fetchData() {
    try {
        const response = await fetch("https://api.example.com/data");
        const data = await response.json();
        return data;
    } catch (error) {
        console.error("Failed to fetch:", error);
        return null;
    }
}

Desugared:

function fetchData() {
    return fetch("https://api.example.com/data")
        .then(response => response.json())
        .catch(error => {
            console.error("Failed to fetch:", error);
            return null;
        });
}