Map

Explanation

Maps are one of the most fundamental data structures in programming. Every time you use a JavaScript object ({}), a Python dict, a Java HashMap, or a Go map, you're using a map. The underlying implementation is almost always a hash table (some language implementations use red-black trees for ordered maps). The key insight is that maps provide fast arbitrary-key lookup — unlike arrays, which only support integer index lookups. In JavaScript, there are two kinds of maps: the plain object ({}) and the Map object. Plain objects are maps with string/symbol keys, prototype chain pollution, no guaranteed iteration order (though modern engines preserve insertion order for string keys in practice), and no .size property. The Map class is a proper map that accepts any key type, guarantees insertion-order iteration, exposes .size, and has slightly better performance for frequent additions/deletions. Common patterns: frequency counters (count how many times each value appears), memoization caches (store previously computed results by input key), lookup tables (map IDs to objects for O(1) retrieval instead of O(n) array finds), and grouping (group items by a property). The groupBy pattern — iterating a collection and appending items to map[key] arrays — is arguably the single most common map operation in real codebases. ES2024 introduced Object.groupBy() and Map.groupBy() as built-in methods, but the pattern of using a Map as a grouping accumulator predates these additions by decades.

Code Example

// JavaScript Map vs plain object

// Use Map when: keys aren't strings, or size/iteration order matters
const userMap = new Map();
userMap.set(42, { name: 'Alice' }); // numeric key — not possible with object
userMap.set(43, { name: 'Bob' });
console.log(userMap.size);          // 2
console.log(userMap.get(42));       // { name: 'Alice' }

// Frequency counter — most common map pattern
function wordFreq(text) {
  const freq = new Map();
  for (const word of text.toLowerCase().split(/\s+/)) {
    freq.set(word, (freq.get(word) ?? 0) + 1);
  }
  return freq;
}

// Grouping pattern
function groupBy(arr, keyFn) {
  const groups = new Map();
  for (const item of arr) {
    const key = keyFn(item);
    if (!groups.has(key)) groups.set(key, []);
    groups.get(key).push(item);
  }
  return groups;
}

const items = [{type:'a',v:1},{type:'b',v:2},{type:'a',v:3}];
const grouped = groupBy(items, x => x.type);
console.log([...grouped.get('a')]); // [{type:'a',v:1}, {type:'a',v:3}]

Why It Matters for Engineers

Maps are the go-to tool for reducing algorithm time complexity. Whenever you find yourself searching an array for an item (O(n)), ask whether that array should be a Map. Converting a list of users to a Map keyed by user ID turns O(n) lookups into O(1) — a 1000x speedup for 1,000 users. Understanding the distinction between plain objects and Map objects in JavaScript matters for correctness, not just performance. Using an object with untrusted user-provided keys can cause prototype pollution bugs (if someone passes '__proto__' as a key). Using a plain object when you need iteration order or a size count leads to bugs. Knowing which to reach for and why is a mark of a careful engineer.