
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.

Booleans


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


ES modules give JavaScript first-class support for splitting code across files. Each file is its own module with a private scope - only what you explicitly export is visible to importers.

<ExamplePair>
<ExampleProse>

**Named exports** are the workhorse of ES modules. A file can export any number of named bindings; importers pick what they need. Names are fixed - renaming at the import site uses `as`.

</ExampleProse>
<ExampleCode>

```js
// math.js
export function add(a, b) { return a + b; }
export function multiply(a, b) { return a * b; }
export const PI = 3.14159;

// main.js
import { add, PI } from "./math.js";
import { multiply as mul } from "./math.js";

console.log(add(2, 3));  // 5
console.log(PI);         // 3.14159
console.log(mul(4, 5));  // 20

// Import everything under a namespace
import * as math from "./math.js";
console.log(math.add(1, 1)); // 2
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

**Default exports** let a module export one primary value. Importers choose the local name freely - no braces required. A module can have both a default export and named exports.

</ExampleProse>
<ExampleCode>

```js
// logger.js
export default function log(msg) {
  console.log(`[LOG] ${msg}`);
}
export const LOG_LEVEL = "info";

// app.js
import log, { LOG_LEVEL } from "./logger.js";
// The importer chose "log" - could have been "writeLog", "print", anything

log("server started");     // [LOG] server started
console.log(LOG_LEVEL);    // info
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

Circular imports - where A imports B and B imports A - are allowed by the spec but produce `undefined` for bindings that haven't been initialised yet at the point of import. The fix is to extract the shared code into a third module.

</ExampleProse>
<ExampleCode>

```js
// a.js
import { b } from "./b.js";
export const a = "a";
console.log("in a, b is:", b); // "b" - b.js finished evaluating before this line

// b.js
import { a } from "./a.js";
export const b = "b";
console.log("in b, a is:", a); // undefined - a.js hasn't finished evaluating yet

// The order matters and is hard to predict at scale.
// Solution: move shared exports to shared.js and import from there.
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

**CJS/ESM interop**: Node.js defaults to CommonJS (`require`). To use ES modules, either name the file `.mjs` or add `"type": "module"` to `package.json`. Dynamic `import()` works in both module systems and is the bridge when you need to load an ESM module from CJS code.

</ExampleProse>
<ExampleCode>

```js
// package.json: { "type": "module" } - all .js files are ESM

// Static import - resolved at parse time, hoisted, cannot be conditional
import { add } from "./math.js";

// Dynamic import - returns a Promise, works anywhere, can be conditional
async function loadPlugin(name) {
  if (name === "math") {
    const { add } = await import("./math.js");
    return add;
  }
}

// In a CJS file (.cjs or without "type":"module"), use dynamic import
// to load ESM-only packages
async function main() {
  const { default: chalk } = await import("chalk"); // chalk v5+ is ESM-only
  console.log(chalk.green("hello"));
}
```

</ExampleCode>
</ExamplePair>

<InProduction>
Default exports look convenient but they hurt refactor safety in shared code: the import name is chosen by the importer, not the author, so automated renames don't propagate and static analysis tools can't reliably track usage. A library that exports `default function process()` will be imported as `doThing`, `handleIt`, and `runProcess` across a large codebase - you lose the single source of truth that named exports provide. Reserve default exports for app-level files where one file represents one feature or page; use named exports everywhere else. Most team style guides (Airbnb, Google) enforce this and so do many ESLint rules.
</InProduction>


ES module import/export, default vs named exports, circular imports, and CJS interop.