When to ditch reduce() for a for...of loop in JavaScript

The `reduce()` Over-Enthusiasm Problem

There was a time, not too long ago, when the JavaScript array method reduce() felt like the ultimate solution to every problem. Need to build a lookup table from an array? reduce(). Need to group items by a property? reduce(). Filter an array? You guessed it, reduce(). Transform an array into something else entirely? reduce() was the tool.

This obsession with reduce(), while born from a desire for functional purity and conciseness, often leads to code that is unnecessarily complex, harder to read, and sometimes, even less performant than a straightforward imperative loop. The core issue is that reduce() is designed for a single purpose: to reduce an array down to a single value. When you try to contort it into performing multiple operations like filtering, mapping, and then aggregating, you end up with a callback function that becomes a sprawling mess. This is like using a screwdriver to hammer a nail – it might eventually work, but it’s not the right tool for the job, and you risk damaging the screwdriver (or your code).

Consider the common scenario of creating a lookup table or an object from an array of items. The goal is to transform an array like [{id: 1, name: 'Alice'}, {id: 2, name: 'Bob'}] into an object like {1: {id: 1, name: 'Alice'}, 2: {id: 2, name: 'Bob'}}. A reduce() approach might look like this:

const users = [
  { id: 1, name: 'Alice' },
  { id: 2, name: 'Bob' }
];

const userMapReduce = users.reduce( (acc, user) => {
  acc[user.id] = user;
  return acc;
}, {});

This works. The accumulator acc starts as an empty object, and for each user, we add a property to it keyed by the user's ID, assigning the user object as the value. It’s functional and, for simple cases, quite readable.

The Clarity of `for...of`

Now, let’s look at the same task using a for...of loop:

const users = [
  { id: 1, name: 'Alice' },
  { id: 2, name: 'Bob' }
];

const userMapLoop = {};
for (const user of users) {
  userMapLoop[user.id] = user;
}

Which is easier to understand at a glance? For most developers, the for...of loop wins. It explicitly states the intent: iterate over each user in the users array and perform an action. There's no need to decipher the role of an accumulator or remember to return it. The state mutation (adding a property to userMapLoop) is direct and imperative. This aligns more closely with how many developers naturally think about sequential operations.

When `reduce()` Becomes a Hindrance

The problems with reduce() compound when the logic inside the callback grows. Imagine you need to not only create a lookup table but also filter out users with specific IDs or transform some of their properties before adding them to the map. Trying to cram all this into a single reduce() callback is a recipe for unmaintainable code. The callback becomes a mini-program, violating the single responsibility principle and making it difficult to test or reason about in isolation.

For instance, if you wanted to create a map of active users (where `isActive: true`) and only include their names, a reduce() approach might look like this:

const users = [
  { id: 1, name: 'Alice', isActive: true },
  { id: 2, name: 'Bob', isActive: false },
  { id: 3, name: 'Charlie', isActive: true }
];

const activeUserNamesMapReduce = users.reduce( (acc, user) => {
  if (user.isActive) {
    acc[user.id] = user.name;
  }
  return acc;
}, {});

This callback now contains conditional logic. If the array were larger and the logic more complex, readability would plummet. The initial intention of reduce()—to aggregate into a single value—is stretched thin here.

The Case for Chaining Simple Methods or Using `for...of`

A more idiomatic and readable approach for the second example would be to chain simpler array methods or to use a loop. Chaining filter() and map() before potentially reducing (if a single value was truly needed) or simply building an object with a loop offers much greater clarity.

Using for...of for the same task:

const users = [
  { id: 1, name: 'Alice', isActive: true },
  { id: 2, name: 'Bob', isActive: false },
  { id: 3, name: 'Charlie', isActive: true }
];

const activeUserNamesLoop = {};
for (const user of users) {
  if (user.isActive) {
    activeUserNamesLoop[user.id] = user.name;
  }
}

This code is immediately understandable. The loop iterates, and inside, a clear condition checks if the user is active. If so, a property is added to the result object. This approach is declarative about the steps involved and easy to debug.

Performance-wise, while reduce() can be highly optimized by JavaScript engines, the overhead of the function call for each element, especially with complex callbacks, can sometimes make a well-written for...of loop competitive or even faster. The V8 engine, for example, is excellent at optimizing simple loops. The primary benefit, however, remains clarity and maintainability. When a task involves more than just a single aggregation, stepping back from reduce() to a for...of loop or a series of chained, simpler array methods (like filter().map()) leads to code that is easier to read, understand, and maintain over time. The key is to choose the tool that best communicates the intent of the operation, not the one that fits a perceived functional programming dogma.

When `reduce()` Still Shines

This isn't to say reduce() is without its merits. It excels when the goal is genuinely to boil an array down to a single accumulated value. Examples include:

• Summing all numbers in an array.
• Calculating the total price of items in a shopping cart.
• Finding the maximum or minimum value in a list.
• Aggregating counts or statistics into a single object.

In these cases, reduce() is concise and directly expresses the intent. The confusion arises when developers try to force other array operations—like mapping or filtering—into the reduce() callback instead of using the dedicated methods for those tasks or opting for a loop when the combined logic becomes too convoluted.

What nobody has fully addressed yet is the long-term impact on codebases when developers default to reduce() for everything. While it might seem elegant initially, it can lead to a steep learning curve for less experienced team members and increase the cognitive load required to understand complex operations. Prioritizing readability and maintainability, even if it means a few extra lines of code in a loop, often proves more beneficial in the long run.