Maps, Sets, objects & arrays: choosing the collection

Each built-in collection is good at answering one question:

The difference that bites first is cost. array.includes(x) and array.find(…) walk the array from the front until something matches — and on a miss they check every element. set.has(x) and map.get(k) don't scan. The ECMAScript spec only promises access times that are, on average, "sublinear on the number of elements" (better than a scan, not necessarily constant). V8, the engine in Chrome and Node, builds Map and Set on hash tables, so there a lookup stays about as fast as the collection grows.

// 10,000 events × up to 5,000 comparisons each
events.filter((e) => !blockedIds.includes(e.userId));

// Build the Set once (one pass), then 10,000 events × 1 lookup each
const blocked = new Set(blockedIds);
events.filter((e) => !blocked.has(e.userId));

One includes on a short array is fine. The bug is the loop around it: a scan inside a loop is n × m work, so doubling both lists quadruples the time. When you see includes, find or indexOf inside map, filter or a for, build a Set or Map once, outside the loop.

An orders screen gets two lists from the API and has to join, clean and summarise them:

type Customer = { id: number; name: string };
type Order = { id: number; customerId: number; status: "open" | "shipped"; tags: string[] };

// 1. Index once: id → customer. One pass, then every lookup is a get.
const customersById = new Map(customers.map((c) => [c.id, c]));

const rows = orders.map((o) => ({
  ...o,
  customerName: customersById.get(o.customerId)?.name ?? "(unknown)",
}));

// 2. Dedupe primitives with a Set. First-seen order is kept.
const allTags = [...new Set(orders.flatMap((o) => o.tags))];

// 3. Dedupe objects by a key, not by identity.
const uniqueOrders = [...new Map(orders.map((o) => [o.id, o])).values()];

// 4. Count with a Map.
const tagCounts = new Map<string, number>();
for (const tag of orders.flatMap((o) => o.tags)) {
  tagCounts.set(tag, (tagCounts.get(tag) ?? 0) + 1);
}

What each line is doing:

• new Map(customers.map((c) => [c.id, c])) — the Map constructor takes an iterable of [key, value] pairs. Building it is one pass over customers; after that, joining 10,000 orders costs 10,000 gets, not 10,000 scans of the customer list (customers.find(…) inside orders.map is the slow version).
• ?.name ?? "(unknown)" — get returns undefined for a missing key, so an order whose customer was deleted gets a placeholder instead of a crash.
• [...new Set(…)] — a Set drops repeats as you add them, and the spread turns it back into an array. Array.from(set) does the same.
• The Map dedupe — new Set(orders) would keep both copies of order 7 when two pages of results overlap: they are different objects, and a Set compares objects by identity. Keying a Map by id collapses them. When a key repeats, set replaces the value but the key keeps its first position, so this keeps the last copy in the first copy's place.
• tagCounts.get(tag) ?? 0 — the first time a tag is seen, get returns undefined, so start from 0. (|| 0 works here too, because a stored count is never 0; ?? says what you mean.)

To count entries, read map.size or set.size — a property, not a method. Object.keys(obj).length is the object equivalent, and it builds a whole array of keys each time you ask.

A plain object works as a lookup table until the keys stop being yours. Three traps, all real.

1. Every object already has keys

{} inherits from Object.prototype, so it already "contains" constructor, toString, hasOwnProperty and friends. Count words from user text with an object and one of them will eventually be "constructor":

const counts = {};
for (const w of ["to", "constructor", "to"]) {
  counts[w] = (counts[w] || 0) + 1;
}
counts.to;          // 2
counts.constructor; // "function Object() { [native code] }1"

counts["constructor"] was the inherited Object function — truthy — so || 0 never kicked in, and function + 1 is string concatenation. Switching to ?? 0 doesn't help (a function isn't nullish), and neither does w in counts, which also sees inherited keys.

"__proto__" is worse: assigning to it calls a setter that swaps the object's prototype (or silently ignores a non-object value), and with keys an attacker controls this is the doorway to prototype pollution. MDN's Map page lists it as the security difference: a Map is safe with user-provided keys.

Fixes, best first: use a Map; or create the object with Object.create(null) (no prototype, no inherited keys — this is what Object.groupBy returns); or check Object.hasOwn(obj, key) (ES2022) before reading. hasOwn alone still can't store a "__proto__" key.

2. Integer-like keys jump the queue

An object's keys are ordered, but not simply. Keys that look like array indexes come first, in ascending numeric order; other strings follow in the order they were added:

Object.keys({ high: 3, 10: "x", low: 1, 2: "y" }); // ["2", "10", "high", "low"]

An object keyed by numeric id therefore iterates in id order, not the order you inserted — sort by date, index by id, and the dates come back scrambled. Map iterates in insertion order, always. MDN's advice for objects is not to rely on property order at all.

3. The keys come back as strings

Object.keys, Object.entries, for…in and Object.groupBy all hand you string keys, even if you wrote numbers. TypeScript knows: Object.keys returns string[], so Object.keys(byId).includes(7) is a compile error, and the honest conversion is Object.keys(byId).map(Number). A plain as number[] is rejected (the types don't overlap); as unknown as number[] compiles, and is wrong at runtime.