• Book: TypeScript Essentials
• Also by me: The TypeScript Library — the 5-book collection
• My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
• Me: xgabriel.com | GitHub

You open a file in the orders service you have not touched in two years. There is a function called monthlyRevenueByCategory. It is thirty-two lines. The first eight declare an empty object, an empty array, and three counters. The next twenty are nested if blocks, an early continue, and a // special case comment that does not explain itself. The last four flatten the result. You have to add one thing (group by region as well as by category) and you spend forty minutes reading the loop before you trust yourself to touch it.

That function is the cost of writing TypeScript like it was 2014.

The runtime caught up. Array methods, Object.groupBy, generators, and the ES2025 iterator helpers cover roughly nine out of every ten places you would have reached for a for loop in 2018. The remaining one in ten is where the loop still earns its keep: early break with a side effect, parallel iteration, hot numeric loops. This post is a tour of where each tool wins and how to tell them apart at a glance.

Version requirements:

• TypeScript 5.7+ with --target es2024 for typed Object.groupBy and Map.groupBy.
• TypeScript 6.0 with --target es2025 for iterator-helper types.
• Node 21+ for Object.groupBy, Node 22+ for iterator helpers.
• Bun 1.1.31+ and Deno 2.0+ for iterator helpers; older Bun/Deno already cover Object.groupBy.

On older Node, array methods work today; the rest lands when you upgrade.

The thirty-line loop, three lines later

Here is the actual shape of that function. Order data coming in, monthly revenue grouped by category coming out.

type Order = {
  id: string;
  category: "books" | "audio" | "video";
  region: "us" | "eu" | "apac";
  total: number;
  paidAt: Date;
};

function monthlyRevenueByCategory(
  orders: Order[],
  month: number,
  year: number,
): Record<string, number> {
  const result: Record<string, number> = {};
  for (let i = 0; i < orders.length; i++) {
    const order = orders[i];
    if (order.paidAt.getMonth() !== month) {
      continue;
    }
    if (order.paidAt.getFullYear() !== year) {
      continue;
    }
    if (result[order.category] === undefined) {
      result[order.category] = 0;
    }
    result[order.category] += order.total;
  }
  return result;
}

You can read it. You will not enjoy it. The loop is doing four jobs at once, all interleaved: filter by month, filter by year, group by category, sum totals.

Here is the same function with the tools that shipped in ES2024 and were typed in TypeScript 5.7.

function monthlyRevenueByCategory(
  orders: Order[],
  month: number,
  year: number,
): Record<string, number> {
  const inMonth = orders.filter(
    (o) => o.paidAt.getMonth() === month && o.paidAt.getFullYear() === year,
  );
  const grouped = Object.groupBy(inMonth, (o) => o.category);
  return Object.fromEntries(
    Object.entries(grouped).map(([cat, list]) => [
      cat,
      (list ?? []).reduce((sum, o) => sum + o.total, 0),
    ]),
  );
}

Three operations, three lines. Filter, group, reduce. Each says what it does. The Record<string, number> return is exactly what you wrote before. The compiler narrows through Object.groupBy so you do not need a cast.

When the request comes in to add region grouping, you change one callback. (o) => o.category becomes (o) =>${o.category}:${o.region}``. Forty-minute archaeology becomes a one-line edit.

The 90% case: filter, map, reduce, group

Most loops in a TypeScript codebase are not exotic. They take an array of things, transform each one, drop the ones you do not want, and either collect the rest or accumulate into a single value. Every one of those has a one-line array method.

`typescript
// Transform: every element to a new shape.
const titles = books.map((b) => b.title);

// Filter: keep what matches.
const inStock = books.filter((b) => b.inventory > 0);

// Reduce: collapse to a single value.
const totalPages = books.reduce((sum, b) => sum + b.pages, 0);

// Both: filter then transform, in two passes.
const slugs = books.filter((b) => b.published).map((b) => b.slug);
`

A note on the filter-then-map pattern that older guides call "two passes, slow." In practice the difference is dominated by the work inside your callback, not the iteration overhead. If profiling shows the array operation is the bottleneck, jump to the iterator helpers section below: that is the single-pass version. For everything else, write the readable form.

Object.groupBy is the new reach. Before ES2024, the recipe was array.reduce((acc, x) => { ... acc[key] = ... ; return acc; }, {}). That works, but the body is harder to read than it should be, and the type of acc requires a cast or an explicit accumulator type at the call site. Object.groupBy deletes the ceremony.

`typescript
const byAuthor = Object.groupBy(books, (b) => b.authorId);
// type: Partial<Record<string, Book[]>>
`

Two things to know. First, the values are Book[] | undefined because Partial<Record<...>> accounts for the fact that nothing was added at every possible key — the union with undefined is the compiler being honest. Use ?? [] when you iterate. Second, if you want a Map keyed on something other than a string (object identity, a Date, a token), reach for Map.groupBy instead. Same shape, Map<K, T[]> instead of Record<string, T[]>.

Runtime support: Node 21+, Bun 1.1+ (the early-2024 issue with Object.groupBy was fixed), Deno 1.39+, every evergreen browser from early 2024 onward. On the TypeScript side, set --target es2024 (TypeScript 5.7+ supports the target directly) or add "lib": ["es2024.object"] if you are pinned to an older target.

When the loop still earns its keep

The 10% where loops are the right tool is small but real. Three patterns.

Early break with side effect

You are scanning a stream of events for the first one matching a condition, and the moment you find it you fire a side effect. find returns the value but cannot fire the effect cleanly. some returns a boolean and discards the value.

`typescript
for (const event of audit) {
if (event.kind === "user.suspended") {
await notifyOpsChannel(event);
cursor.markAt(event.id);
break;
}
}
`

You can squint and rewrite it with find and a separate if, but the loop reads like the spec: walk the audit log, when you see a suspension fire the alert and stop. The early break is the point of the loop.

Parallel iteration over multiple sequences

JavaScript has no built-in zip. When two arrays are coupled by index (matrix row and column header, question and answer, input and weight), the indexed for is the cleanest expression.

`typescript
function* zipQA(questions: Question[], answers: Answer[]) {
for (let i = 0; i < questions.length; i++) {
const q = questions[i];
const a = answers[i];
if (a === undefined) {
throw new Error(`No answer for question ${q.id}`);
}
yield { question: q, answer: a };
}
}
`

You can build a zip helper, and most utility libraries ship one. If you reach for it often, do that. For one-off coupled iteration, the indexed for is direct and has no closure overhead.

Hot tight numeric loops

The case where you should micro-optimize is a loop that runs a million times in a render frame, an audio buffer, or a hot path profiling proved is your bottleneck. Everything else, leave alone.

`typescript
const pixels = imageData.data;
for (let i = 0; i < pixels.length; i += 4) {
const luminance =
0.2126 * pixels[i] + 0.7152 * pixels[i + 1] + 0.0722 * pixels[i + 2];
pixels[i] = pixels[i + 1] = pixels[i + 2] = luminance;
}
`

Each frame skipped, each closure not allocated, matters here. The indexed for tends to JIT better in V8 than forEach on a Uint8ClampedArray because the bounds are visible and the body has no closure allocation — profile your workload to confirm. This is the one place where the loop wins on raw numbers.

The trap is convincing yourself this case applies to your CRUD endpoint. It does not. Profile first; rewrite if the profile demands it.

Generators for lazy custom sequences

The for loop has one more job nobody talks about: producing a sequence on demand instead of materializing it. That job belongs to generators now.

`typescript
function* paginate(
fetchPage: (cursor: string | null) => Promise<{
items: T[];
next: string | null;
}>,
): AsyncGenerator {
let cursor: string | null = null;
do {
const { items, next } = await fetchPage(cursor);
for (const item of items) {
yield item;
}
cursor = next;
} while (cursor !== null);
}

for await (const order of paginate(fetchOrdersPage)) {
if (order.flagged) {
await reviewOrder(order);
}
}
`

What the generator buys you: the consumer reads the API as if it were one infinite array, the producer never holds more than a single page in memory, and the page-cursor logic lives in one place. Before generators, the same code was a recursive callback chain or a hand-rolled iterator object with next() methods. Now it is a function with one * and one yield.

For synchronous lazy sequences (the first N primes, a rolling window, an arithmetic progression), sync generators compose with for...of and slot directly into the iterator helpers below.

Iterator helpers tie it together

The piece that landed in 2025 and changed the shape of TypeScript code in 2026 is iterator helpers — the array methods you already know (map, filter, take, drop, flatMap, reduce, some, every, find, forEach, toArray) but on iterators directly. The array.filter().map() chain materializes intermediate arrays. The iterator-helper version processes one element end to end and stops the moment you stop asking.

`typescript
function* naturals() {
for (let n = 1; ; n++) yield n;
}

const firstTenSquaresOver50 = naturals()
.map((n) => n * n)
.filter((sq) => sq > 50)
.take(10)
.toArray();
// [64, 81, 100, 121, 144, 169, 196, 225, 256, 289]
`

The infinite generator does not blow up because .take(10) pulls exactly ten values through the chain and stops. Each value is mapped, filtered, and either taken or skipped before the next one is generated. No intermediate arrays.

The same shape works on the paginate generator above:

`typescript
const recentFailedTotal = await paginate(fetchOrdersPage)
.filter((o) => o.status === "failed")
.take(100)
.reduce((sum, o) => sum + o.total, 0);
`

You walk through the order pages until you have collected 100 failures, summing as you go. The reduce is the consumer; everything upstream pulls one element at a time. If failure 100 lives on page 3, pages 4 onward are never fetched.

This is also the answer to the "but isn't filter().map() two passes" worry from earlier. When the chain is on an iterator, it is one pass by construction. Iterator.from(arr) at the top of the chain flips the same readable code into single-pass execution.

Runtime support: iterator helpers shipped in ES2025 and are available in Node 22+, Chrome 122+, Firefox 131+, Safari 18.4+, Bun 1.1.31+, and Deno 2.0+. TypeScript 6.0 added the types under --target es2025 and --lib es2025. The async-iterator version of the helpers is still a Stage-2 proposal. For async, the for await...of loop with a body is currently the cleanest expression; the sync helpers cover everything else.

(Discriminated-union and Extract patterns pair well with these chains: the compiler carries narrow types through .filter, .map, and .reduce end to end when the callbacks are pure.)

When in doubt, write the loop

The honest version: a for...of loop in TypeScript is fine. Loops are not forbidden. Array methods, groupBy, generators, and iterator helpers are now mature enough to be the default; the loop is a deliberate fallback.

The decision tree I run in my head:

• Transforming, filtering, accumulating, or grouping a finite collection: array methods. groupBy for grouping. No reach for the loop.
• Producing a lazy or infinite sequence: generator function.
• Composing transformations on a generator or large array, especially with early termination: iterator helpers.
• Walking two coupled sequences in lockstep: indexed for.
• Searching with an early break that fires a side effect: for...of with break.
• Hot numeric loop on a typed array, profiled: indexed for.

If you cannot put the candidate code into one of the first three buckets, the loop is the answer. Do not spend twenty minutes contorting a reduce to avoid a for that would have read straight.

Next time you find yourself declaring result = {} and i = 0 on consecutive lines, pause. There is almost certainly an array method, a groupBy, or a generator that wants the job. Save the loop for the work the loop is uniquely good at.

If this was useful

This is the iteration chapter from TypeScript Essentials, condensed into one post. The book starts from "you already write JavaScript" and walks the type system end-to-end across Node, Bun, Deno, and the browser, including the runtime pieces — Object.groupBy, generators, iterator helpers, async iteration — that change how the type-level patterns compose in production code.

The full collection (The TypeScript Library) is five books that share a vocabulary. Books 1 and 2 are the core path. Books 3 and 4 are bridges if your team comes from the JVM or PHP world. Book 5 is for whoever is owning the build, the monorepo, and the dual-publish problem.

• TypeScript Essentials — From Working Developer to Confident TS, Across Node, Bun, Deno, and the Browser: amazon.com/dp/B0GZB7QRW3 — the entry point. Types, narrowing, modules, async, daily-driver tooling.
• The TypeScript Type System — From Generics to DSL-Level Types: amazon.com/dp/B0GZB86QYW — generics, mapped and conditional types, infer, template literals, branded types.
• Kotlin and Java to TypeScript — A Bridge for JVM Developers: amazon.com/dp/B0GZB2333H — variance, null safety, sealed classes to unions, coroutines to async/await.
• PHP to TypeScript — A Bridge for Modern PHP 8+ Developers: amazon.com/dp/B0GZBD5HMF — sync to async paradigm, generics, discriminated unions for PHP-shaped brains.
• TypeScript in Production — Tooling, Build, and Library Authoring Across Runtimes: amazon.com/dp/B0GZB7F471 — tsconfig, build tools, monorepos, library authoring, dual ESM/CJS, JSR.

All five books ship in ebook, paperback, and hardcover.