Monads

"Monad" has a fearsome reputation, but the idea is gentle and you have already met it in disguise. A monad is a design pattern for sequencing steps that each carry a little extra baggage — the possibility of failure, a list of results, an effect — while keeping the plumbing for that baggage out of your way. You write the happy path; the monad threads the baggage through automatically.

Concretely, a monad is a container type plus two operations:

of (also called return or unit): wrap a plain value into the container.
flatMap (also called bind or >>=): take a contained value, run a function that produces a new container, and flatten the result so you don't end up with a container-of-a-container.

That's it. Everything else is examples. Let's meet two friendly ones.

Maybe: computations that might fail

Maybe is a sum type: a value is either Just x (success, carrying x) or Nothing (failure, carrying nothing). It replaces error-prone null with something the type-checker forces you to handle. The magic is flatMap: chain steps that might fail, and the moment one returns Nothing, the rest are skipped — no cascade of if (x !== null) checks.

type Maybe<T> = { kind: "just"; value: T } | { kind: "nothing" }; const just = <T>(value: T): Maybe<T> => ({ kind: "just", value }); const nothing: Maybe<never> = { kind: "nothing" }; // flatMap: if we have a value, run f on it; if not, stay Nothing function flatMap<A, B>(m: Maybe<A>, f: (a: A) => Maybe<B>): Maybe<B> { return m.kind === "just" ? f(m.value) : nothing; } const safeDiv = (a: number, b: number): Maybe<number> => b === 0 ? nothing : just(a / b); // chain: 100 / 2, then / 5, then / 0 -> short-circuits to Nothing const good = flatMap(safeDiv(100, 2), (x) => safeDiv(x, 5)); const bad = flatMap(safeDiv(100, 2), (x) => safeDiv(x, 0)); console.log("good:", good); // { kind: "just", value: 10 } console.log("bad:", bad); // { kind: "nothing" } — failure propagated

Notice you never wrote "if the first division failed, skip the second." flatMap did the short-circuiting for you. That is the monad earning its keep: the failure plumbing is hidden inside flatMap, and your code reads like the happy path.

List: computations with many results

The very same pattern, with a different baggage: a list monad models a computation that can return many answers. Here of is "a one-element list," and flatMap runs a function that returns a list for each element, then flattens — exactly JavaScript's built-in Array.prototype.flatMap. It automatically explores every combination.

// for each roll of die A, pair it with each roll of die B: all combinations const dice = [1, 2, 3, 4, 5, 6]; const sums = dice.flatMap((a) => dice.flatMap((b) => [a + b]), ); console.log("number of outcomes:", sums.length); // 36 console.log("ways to make 7:", sums.filter((s) => s === 7).length); // 6

flatMap here is doing the nested-loop bookkeeping — "for every a, for every b" — behind one clean expression. Same two operations (of and flatMap), completely different behaviour: that reusability is exactly why the abstraction is worth naming.

Maybe, List, and the lazy world of streams feel unrelated, yet each is a container with the same two operations, and each obeys the same three monad laws that make chaining behave sensibly:

Left identity: flatMap(of(x), f) is just f(x) — wrapping then immediately binding does nothing extra.
Right identity: flatMap(m, of) is just m — binding with the plain wrapper changes nothing.
Associativity: chaining a then b then c gives the same result however you bracket the binds.

These laws are why you can build long pipelines with confidence. And they're why languages add special sugar for monads — Haskell's do-notation, and JavaScript's async/await, which is really flatMap for the Promise monad ("a value that will arrive later"). Every time you await, you're binding a monad.

Why the pattern is worth learning

One idea, many effects. Failure (Maybe), multiplicity (List), asynchrony (Promise), state, logging — all sequenced by the same flatMap shape. Learn it once, recognise it everywhere.
The plumbing disappears. Null-checks, nested loops, callback pyramids — the monad hides the repetitive threading so your code shows the intent.
Effects stay honest. Because the effect lives in the type (a Maybe<number> announces it might fail), you can't forget to deal with it — the purity of the surrounding code is preserved.

A few honest cautions as you start:

flatMap, not map. If your step returns a new container (a => Maybe<B>), use flatMap. Using plain map leaves you with a Maybe<Maybe<B>> — a nested box you then have to unwrap by hand. Flattening is the whole point of flatMap.
Don't reach inside blindly. The reason to use flatMap is to avoid pattern-matching on Just/Nothing at every step. If you find yourself unwrapping and re-wrapping constantly, you're fighting the abstraction.
Don't over-mystify it. A monad is not a mystical object — it's just a type with of and a law-abiding flatMap. You've been using Promises and arrays' flatMap all along.