FeedDiscussion
Map and Set in JavaScript: Why { } and [ ] Aren't Always Enough
Why does {} sometimes let you overwrite data silently? Try this in your console: const user = {}; user[1] = "Sahil"; user["1"] = "Piyush"; console.log(user); // { '1': 'Piyush' } Two different-looki
sahilxdev.hashnode.dev8 min read
#javascript#web-development#webdev#programming-blogs#chaicode-webdev-cohort-2026#chaiaurcode#chaicohort
Clear write-up, and the SameValueZero note is the right one to flag. Three things worth adding, since they all bite in the exact cases you recommend these for:
SameValueZero also collapses -0 and +0. new Set([0, -0]).size is 1, and map.set(0, 'a').set(-0, 'b') leaves you with one entry. So it is not only NaN that behaves differently from ===; the zeros go the other way.
"Caching by object reference" with a Map is the one recommendation that can leak. A Map holds a strong reference to its keys, so a cache keyed by DOM nodes or by objects keeps them alive forever, even after the rest of the app has dropped them. WeakMap (and WeakSet) exist for exactly that: the entry disappears when the key becomes unreachable. The trade is that a WeakMap has no .size and is not iterable, which is the point.
Map and Set do not survive JSON. JSON.stringify(new Map([['a', 1]])) gives "{}", and so does a Set. People swap an Object for a Map, hit their API layer, and the payload silently empties. [...map] and [...set] are the usual fix, with new Map(parsed) on the way back.
Small one on your prototype point: if you want a dictionary without inherited keys but do not need Map, Object.create(null) gives you an object with no prototype at all. Handy when the keys come from user input and something might be called "constructor" or "proto".