Eloquent JavaScript

1A program is a building of thought

The introduction shows the same program — add numbers 1 to 10 — written in raw binary, then readable assembly, then JavaScript's while loop, then sum(range(1, 10)). The moral is explicit: "A good programming language helps the programmer by allowing them to talk about the actions the computer has to perform at a higher level" (p. 8). This framing, early and concrete, answers the "why do languages exist" question better than most CS textbooks.

2Functions are values — the real rupture

In many languages, functions are special entities. In JavaScript, a function is a value like any other: you can store it in a variable, pass it as an argument, return it from another function. Haverbeke demonstrates this by storing a function in a binding called launchMissiles, then reassigning it to a no-op based on a condition:

let launchMissiles = () => { /* real launch */ };
if (safeMode) {
    launchMissiles = () => {}; // replaced by a no-op
}
launchMissiles(); // does nothing in safe mode

The fact that this is legal — and useful — is the conceptual key that unlocks the rest of the book.

3Closures: the environment travels with the function

When a function is created, it captures its surrounding scope. multiplier(2) returns a function that multiplies its argument by 2 — and that returned function keeps access to the factor binding even after multiplier has returned:

function multiplier(factor) {
    return number => number * factor;
}
let double = multiplier(2);
double(5); // 10 — factor is still accessible

"A good mental model is to think of function values as containing both the code in their body and the environment in which they are created" (p. 72). This one concept is behind:

• event handlers (they capture the DOM element or state at the moment they're created);
• factory functions (each call produces a new function with its own private state);
• partial application (fix some arguments now, supply the rest later);
• a large portion of npm packages (most utility libraries are just closures over configuration).

4filter, map, reduce — thinking in transformations

Chapter 5 works through a dataset of human writing scripts (Latin, Arabic, Han...) using higher-order functions. The recipe analogy lands well: detailed step-by-step instructions vs. "soak, simmer, chop, add" — the second requires understanding a few extra words, but says far more in less space. The final example: computing the average year of origin for living scripts fits in a single readable expression:

SCRIPTS.filter(s => s.living).map(s => s.year)

Select, transform, aggregate. That's what thinking in transformations looks like.

5Prototypes and the secret life of this

JavaScript objects are linked to other objects through a prototype chain. When you access a property that an object doesn't have, the runtime walks up the chain until it finds it or reaches null. That's why arrays have .map() and .filter() without you ever defining them — those methods live on Array.prototype, one step up the chain:

Object.getPrototypeOf([]) == Array.prototype        // true
Object.getPrototypeOf(Array.prototype) == Object.prototype // true
Object.getPrototypeOf(Object.prototype)             // null

The chapter also clarifies why this behaves differently in arrow functions vs regular functions — arrow functions inherit this from their surrounding scope, regular functions get a new this decided by the caller. That's the source of more confusion than any other single JS feature.

6JavaScript is deliberately liberal — this has costs

The language accepts almost anything you type and interprets it in ways you didn't intend. Handy to start with, treacherous at scale:

counter = 0           // missing "let": global created SILENTLY
0 == false            // true (automatic conversion)
0 === false           // false (=== never converts: always prefer it)
"5" - 1               // 4  ("5" becomes a number)
"5" + 1               // "51" (1 becomes text!) — the classic trap

A NaN ("not a number", the result of an invalid operation like "abc" * 2) then propagates silently until you get wrong output with no error message. Haverbeke names these clearly: "Finding the source of such problems can be difficult" (p. 192). The fix (strict mode, === everywhere, TypeScript) is presented honestly, not evangelized.

7From callback hell to async/await

JavaScript runs on a single thread: it can't block waiting for a network response without freezing the whole page. The chapter walks the full history of how that problem was solved:

• Callbacks — you pass a function to be called when the result arrives. Simple, but nesting five of them to sequence five operations produces an unreadable pyramid.
• Promises — a receipt for a future value. Instead of nesting, you chain: .then().then().catch() stays flat. Errors propagate automatically.
• async/await — syntax sugar over Promises that reads like synchronous code. const data = await fetch(url) looks immediate; the engine handles the Promise underneath.

"An async function implicitly returns a promise and can, in its body, await other promises in a way that looks synchronous" (p. 283). You still need to understand Promises underneath to debug what goes wrong, but async/await is where you live day to day.

8Modules: LEGO instead of mud

Before ES modules (2015), all JavaScript ran in a shared global scope, and any two scripts could overwrite each other's variables without warning. The module flips that: each file chooses what it exposes and what it borrows.

// cart.js: this file decides what gets out, the rest stays private
export function total(lines) { ... }
const VAT = 0.2                 // invisible outside: no collision possible

// invoice.js: borrow it by name, the well-defined connector
import { total } from './cart.js'

Haverbeke calls this "LEGO, where pieces interact through well-defined connectors, and less like mud, where everything mixes with everything else" (p. 250): export and import are those connectors. npm ships over three million packages, "a large portion of those are rubbish, to be fair" (p. 254). The honest caveat about npm quality is characteristic of the book's tone.