Stop using Array.map() everywhere 🥵

Hi @suprabhasupi and thanks for your article.

I wanted to point out that you could also have used map in a different way and still have the expected result.

const root = document.getElementById("root");

if (!root) {
  throw new Error("Root not found");
}

const fruits = ["banana", "apple", "pear"];

const indexed = fruits.map((fruit, index) => {
  return `#${index + 1}: ${fruit}`;
});

const html = indexed.join("<br>");

root.innerHTML = html;

Although I agree with you, I would change the title from Stop using Array.prototype.map everywhere to Start learning when to use Array.prototype.map.

A do/don't kind of article would have been great for beginners to quickly catch the idea, and maybe extend the article to some of the most popular array methods as well.

Hard disagree. As others have said, the string concatenation example should have been reduce instead of map, but always favor immutable, functional operations over procedural ones because it is so much easier to introduce bugs in procedural operations like for loops.

Memory consumption is rarely a factor in most JavaScript apps, and garbage collectors get better every year. This is a classic example of a premature optimization. It's better to use map (and reduce!) for pretty much everything, and then go back and optimize into loops where you know there are bottlenecks, after your codebase is more mature.

Getting a new array is very much the point. We do this to avoid side effects that are difficult to track. It’s the same reason functions should return a value, not modify a reference.

Immutability by default is a solid strategy that helps avoid countless bugs. Only modify the original array when you have proven map to be a performance bottleneck - and it’s rare.

map - if you expect an array as a result.
reduce - if you expect one value as a result.
forEach - if you don't need to return a result. Better for sync code.
for of - if you don't need to return a result and you might break the loop. Better for async code.

In your last example the forEach is the wrong choice. A reduce would have been better

I disagree somewhat. While the correct use case for map() is for when you want to transform the items in an array, and you shouldn't use it if you're just carrying out an action on each item, these days loops (as opposed to the forEach() method) are best avoided for most use cases, particularly when using a UI library like React.

Using chainable array methods like map() and forEach() has numerous advantages over a loop:

• It breaks your code into a series of steps, making it easier to understand and reason about than nested loops
• Because the callback for each is a function, you can add type hints for the parameters and return value when using Flow or Typescript to help document what each item represents
• It mitigates the need for multiple levels of indentation

Yes, if you're not changing the data, you should use forEach() rather than map(), but in code reviews I would actively discourage using a loop if you can use forEach() instead.

But yeah it is immediately garbage collected by V8s GC. But still, using map is not recommended for larger arrays, because you may need lot of heap memory at that point in time before it is garbage collected.

As an alternative to the first example I would propose Array.prototype.join(), i.e. remove the text variable and set the HTML to fruits.join(''). In well structured code scope and GC will clean up the fruits array when appropriate.

It's common to have use for both the old array and the new one, e.g. for time travel through app state or when both sets might get rendered depending on user input. When building complex applications one also tends to prefer to avoid data mutations to make code more readable and easier to debug, functional mapping tends to be appropriate for this purpose.

This is cool, I worked on a project that i could see map() everywhere for no reason! As you said, when its working with small data, its fine to use it. But when have a massive amount of data, its complicated. Even more complicated when use micro services and the communication between the services is async. Take aaaages to load.