Iterator helpers: .map(), .filter(), and .take() directly on iterators

Generators and iterators have been part of JavaScript since ES2015, but for nearly a decade they had one glaring gap: you couldn’t .map() or .filter() one directly. Iterator helpers close that gap — and unlike the array methods you already know, they’re lazy.

The old problem: no array methods on iterators

An iterator only guarantees .next() — no .map, no .filter, nothing you’d expect from Array.prototype. The standard workaround was converting to an array first:

function* naturalNumbers() {
  let n = 1;
  while (true) yield n++;
}

// Array.from materializes the whole thing — impossible for an infinite generator
const firstFive = Array.from(naturalNumbers()).slice(0, 5); // hangs forever

That Array.from() call tries to fully drain the iterator into memory before you can do anything with it — which is fine for a short, finite sequence, but breaks down completely for something infinite or simply very large, since you’d be paying the memory and time cost of materializing data you might only need a slice of.

The new methods

Every iterator (including generators) now has these built in:

function* naturalNumbers() {
  let n = 1;
  while (true) yield n++;
}

const firstFiveEvenSquares = naturalNumbers()
  .filter((n) => n % 2 === 0)
  .map((n) => n * n)
  .take(5)
  .toArray();

console.log(firstFiveEvenSquares); // [4, 16, 36, 64, 100]

No Array.from(), no risk of hanging — take(5) stops pulling values from the underlying infinite generator the moment it has 5, and filter/map only ever process the values that actually make it that far.

Method reference

Method	What it does
.map(fn)	Transforms each value lazily
.filter(fn)	Keeps only values matching the predicate
.take(n)	Stops after n values
.drop(n)	Skips the first n values
.flatMap(fn)	Maps then flattens one level, like the array method
.reduce(fn, initial)	Reduces to a single value, consuming the iterator
.toArray()	Materializes the remaining values into an array
.forEach(fn)	Runs a callback for each value, consuming the iterator
.some(fn) / .every(fn) / .find(fn)	Same semantics as the array versions

map, filter, take, drop, and flatMap all return a new iterator without consuming the original one eagerly — they only pull values as needed. reduce, toArray, forEach, some, every, and find are the “terminal” operations that actually drive iteration.

Why laziness matters here

The key difference from Array.prototype methods is that array methods are eager — [1,2,3].map(fn) processes every element immediately and allocates a whole new array, even if you only end up using the first result. Iterator helpers process one value at a time, on demand, which means:

• You can chain operations on an infinite sequence, as long as something downstream (take, find, etc.) eventually stops pulling.
• Intermediate arrays are never allocated — useful when processing a large dataset where materializing every intermediate step would waste memory.

// This line does no work at all yet — nothing has been pulled from the iterator
const pipeline = naturalNumbers()
  .filter((n) => n % 3 === 0)
  .map((n) => n * n);

// Only now does iteration actually start, and it stops as soon as it has 3 values
console.log(pipeline.take(3).toArray()); // [9, 36, 81]

FAQ

Conclusion

Iterator helpers finally let you .map(), .filter(), and .take() directly on any iterator or generator, without first draining it into an array — which was previously either wasteful for large sequences or outright impossible for infinite ones. Reach for them whenever you’re processing a sequence lazily makes sense: infinite generators, large datasets, or any pipeline where you only need the first few results.

References

• Iterator – MDN

• Iterator Helpers – TC39 proposal