When is a `Map` more useful than a plain JavaScript object?

A Map is especially useful when you do not know all the keys in advance, or when a key might be something other than a string. For example, you could associate each object representing a user session with data for that session. A Map accepts keys of any value, including objects and primitives; an ordinary object uses string or symbol keys. [S1][S2]

An object is usually clearer for a fixed-shape record whose fields are known and named ahead of time, such as { theme: "dark", language: "en" }. MDN describes this as a useful distinction: dynamic lookup keys favor considering Map, while known string-keyed data shapes fit ordinary objects naturally. [S1]

So the practical question is: are these named fields in a record, or entries in a lookup that grows and changes?

Here is a small example using made-up values. The object key is deliberately reused so retrieval asks for the exact same key:

const north = { name: "North" };
const prices = new Map();

prices.set(north, 12);
prices.set("standard", 8);

console.log(prices.get(north)); // 12
console.log(prices.size);       // 2

for (const [key, value] of prices) {
  console.log(key, value);
}

set(key, value) stores an entry, get(key) retrieves its value, and .size reports the number of entries. Iterating a Map with for...of yields [key, value] pairs in insertion order. [S2]

For object keys, identity matters: north retrieves the entry because it is the same object used when setting it. A separately created object such as { name: "North" } is not the same key, even though its contents look alike. [S2]

For a fixed record, an object makes the named fields easy to read:

const settings = {
  theme: "dark",
  language: "en"
};

console.log(settings.theme);

That shape is a good fit when theme and language are the known fields you intend to store. But it is not a direct replacement for the earlier Map: ordinary object keys are strings or symbols, and an object is not directly iterable with for...of by default. [S1][S2]

With a Map, the entry count is available as .size, and the entries can be traversed directly as pairs. With an object, you can still enumerate properties using other approaches, but that is a different interface. Choose based on the shape and behavior you want rather than assuming one container is always faster; the cited documentation does not establish a universal performance winner. [S2]

Use this short decision guide:

1. If the data is a record with a known set of string-named fields, start with a plain object.
2. If entries arrive dynamically, keys might be objects or other non-string values, or you want direct insertion-order iteration and .size, consider Map. [S1][S2]
3. If you use objects as Map keys, keep and reuse the same object reference when retrieving the entry. Equal-looking objects are not interchangeable keys. [S2]

For example, a fixed app preference record is naturally expressed as an object; a lookup associating changing runtime objects with values is a natural case to evaluate for Map. This is a choice about data shape and access patterns, not a claim that every lookup needs a Map.