
A higher-order function is a function that takes another function as an argument, returns one, or both. JavaScript treats functions as values that can be stored, passed, and returned like numbers or strings. That's the whole feature.

<ExamplePair>
<ExampleProse>

Passing a callback to a higher-order function is the most common pattern. Array methods like `map`, `filter`, and `forEach` are built-in higher-order functions. The callback you pass is just a value.

</ExampleProse>
<ExampleCode>

```js
const numbers = [1, 2, 3, 4, 5];

// Passing an arrow function as a callback
const doubled = numbers.map((n) => n * 2);
console.log(doubled); // [2, 4, 6, 8, 10]

// The callback is a value - you can store it first
const isEven = (n) => n % 2 === 0;
const evens = numbers.filter(isEven);
console.log(evens); // [2, 4]

// setTimeout is a higher-order function too
setTimeout(() => console.log("done"), 0);
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

A function can return another function. This pattern is called a factory or a closure. Each call to the outer function produces an independent inner function with its own captured variables.

</ExampleProse>
<ExampleCode>

```js
function multiplier(factor) {
  return (x) => x * factor;
}

const double = multiplier(2);
const triple = multiplier(3);

console.log(double(5));  // 10
console.log(triple(5));  // 15
console.log(double(10)); // 20

// Each function independently remembers its factor
const taxes = [100, 250, 80].map(multiplier(1.2));
console.log(taxes); // [120, 300, 96]
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

Array methods pass three arguments to every callback: the current element, its index, and the full array. Passing a function directly as a callback works fine when it only uses the first argument. Problems appear when it reads more.

</ExampleProse>
<ExampleCode>

```js
// This looks fine but breaks
const result = ["1", "2", "3"].map(parseInt);
console.log(result); // [1, NaN, NaN]

// Why: map calls parseInt(element, index, array)
// parseInt("1", 0) = 1   (radix 0 treated as 10)
// parseInt("2", 1) = NaN (radix 1 is invalid)
// parseInt("3", 2) = NaN (radix 2, "3" is not binary)

// Fix: wrap so only the element is forwarded
const correct = ["1", "2", "3"].map((s) => parseInt(s, 10));
console.log(correct); // [1, 2, 3]

// Same issue with Number - but Number ignores extra args, so it's safe
const nums = ["1", "2", "3"].map(Number);
console.log(nums); // [1, 2, 3]
```

</ExampleCode>
</ExamplePair>

<InProduction>
Callback signatures are a contract. When an array method passes `(value, index, array)` and your callback reads more arguments than intended, you get silent misbehavior rather than an error. The `parseInt` example above is the classic case, but the same bug can appear with any multi-parameter function. Wrapping in an arrow (`(s) => fn(s)`) makes the intent explicit and breaks the coupling. TypeScript makes this class of bug impossible: it will flag a signature mismatch at compile time.
</InProduction>


Functions that accept or return other functions - the pattern behind map, filter, and every event listener you've ever written.

Higher-Order Functions and Callbacks


A recursive function is one that calls itself. Every recursion needs a base case (the condition where the function stops calling itself) and a recursive step that shrinks the problem toward that base case.

<ExamplePair>
<ExampleProse>

Factorial is the textbook example. The base case is `n <= 1` (return 1). The recursive step multiplies `n` by the factorial of `n - 1`, which is a smaller version of the same problem.

</ExampleProse>
<ExampleCode>

```js
function factorial(n) {
  if (n <= 1) return 1;       // base case: stop here
  return n * factorial(n - 1); // recursive step: smaller problem
}

console.log(factorial(1)); // 1
console.log(factorial(4)); // 24  (4 * 3 * 2 * 1)
console.log(factorial(6)); // 720

// Call stack for factorial(4):
// factorial(4) -> 4 * factorial(3)
//                     -> 3 * factorial(2)
//                            -> 2 * factorial(1)
//                                   -> 1  (base case)
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

Recursion is the natural shape for traversing nested structures like trees or deeply nested objects. Each level of nesting becomes one level of recursion. An iterative loop would need to track depth manually.

</ExampleProse>
<ExampleCode>

```js
const fileTree = {
  name: "src",
  children: [
    { name: "index.js", children: [] },
    {
      name: "utils",
      children: [
        { name: "math.js", children: [] },
        { name: "string.js", children: [] },
      ],
    },
  ],
};

function printTree(node, depth = 0) {
  const indent = "  ".repeat(depth);
  console.log(indent + node.name);
  for (const child of node.children) {
    printTree(child, depth + 1); // same function, smaller problem
  }
}

printTree(fileTree);
// src
//   index.js
//   utils
//     math.js
//     string.js
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

For bounded inputs, an iterative loop and a recursive function are equally readable. The loop version avoids function call overhead and is sometimes clearer when the problem is simply counting down.

</ExampleProse>
<ExampleCode>

```js
// Recursive factorial
function factorialRecursive(n) {
  if (n <= 1) return 1;
  return n * factorialRecursive(n - 1);
}

// Iterative equivalent - no stack frames, same result
function factorialIterative(n) {
  let result = 1;
  for (let i = 2; i <= n; i++) {
    result *= i;
  }
  return result;
}

console.log(factorialRecursive(6));  // 720
console.log(factorialIterative(6));  // 720
```

</ExampleCode>
</ExamplePair>

<InProduction>
V8 does not optimize tail calls, so every recursive call adds a stack frame. In practice, Node.js and most browsers throw a `RangeError: Maximum call stack size exceeded` at around 10,000 to 15,000 frames. If the input comes from a user (a deeply nested JSON document, a large file tree, user-submitted HTML), recursion will blow the stack. Convert to an iterative approach using an explicit stack (`const stack = [root]; while (stack.length) { ... }`) whenever depth is unbounded. Recursion is safe for compile-time-bounded structures like AST visitors over a grammar you control.
</InProduction>


Functions that call themselves - the natural fit for tree traversal, with a hard stack limit that matters on user-supplied data.

Recursion


A boolean is one of two values: `true` or `false`. Comparisons (`===`, `<`, `>=`) and logical operators (`&&`, `||`, `!`) produce booleans, so they show up everywhere even when you don't declare them explicitly.

<ExamplePair>
<ExampleProse>

Boolean literals are `true` and `false`. `typeof` confirms the type. Comparison expressions evaluate to a boolean you can store or pass like any other value.

</ExampleProse>
<ExampleCode>

```js
const isLoggedIn = true;
const hasErrors = false;

console.log(typeof isLoggedIn); // "boolean"

const age = 20;
const isAdult = age >= 18;
console.log(isAdult); // true

const name = "Alice";
const isEmpty = name === "";
console.log(isEmpty); // false
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

JavaScript has exactly eight falsy values: `false`, `0`, `-0`, `0n`, `""`, `null`, `undefined`, and `NaN`. Everything else is truthy. `Boolean(x)` converts any value to its boolean equivalent, which is what an `if` statement does internally.

</ExampleProse>
<ExampleCode>

```js
// All eight falsy values
console.log(Boolean(false));     // false
console.log(Boolean(0));         // false
console.log(Boolean(-0));        // false
console.log(Boolean(0n));        // false
console.log(Boolean(""));        // false
console.log(Boolean(null));      // false
console.log(Boolean(undefined)); // false
console.log(Boolean(NaN));       // false

// Everything else is truthy
console.log(Boolean("0"));   // true  - non-empty string
console.log(Boolean([]));    // true  - empty array
console.log(Boolean({}));    // true  - empty object
console.log(Boolean(-1));    // true  - non-zero number
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

`==` (loose equality) coerces both sides to the same type before comparing, producing results that surprise almost everyone. `===` (strict equality) never coerces: different types are never equal. Prefer `===` everywhere.

</ExampleProse>
<ExampleCode>

```js
// Loose equality surprises
console.log(0 == false);         // true  (0 coerces to false)
console.log("" == false);        // true  ("" coerces to 0, false to 0)
console.log(null == undefined);  // true  (special case in the spec)
console.log("1" == 1);           // true  (string coerced to number)

// Strict equality - type must match
console.log(0 === false);        // false
console.log("" === false);       // false
console.log(null === undefined); // false
console.log("1" === 1);          // false
```

</ExampleCode>
</ExamplePair>

<InProduction>
Always use `===` and `!==`. The loose equality coercion table (`0 == false`, `"" == false`, `null == undefined`) is not intuitive and produces bugs that are hard to spot in code review. Most ESLint configs include the `eqeqeq` rule that bans `==` outright. Teams that skip it eventually ship a bug where an empty string or zero is treated as falsy in a place that should only treat `null`/`undefined` that way.
</InProduction>


The true/false type - including the eight falsy values, truthy coercion, and why == is a trap you should never step in.