How do you compute the union, intersection, and difference of two JavaScript Sets, both with the built-in Set methods and by hand?

## The built-in methods Set operations were added to the language in ES2025 and shipped across engines during 2023–2024 (Safari 17, Chrome 122, Firefox 127, Node 22). Seven methods arrived together: ```js const a = new Set([1, 2, 3]); const b = new Set([3, 4]); a.union(b); // Set { 1, 2, 3, 4 } a.intersection(b); // Set { 3 } a.difference(b); // Set { 1, 2 } a.symmetricDifference(b); // Set { 1, 2, 4 } a.isSubsetOf(b); // false a.isSupersetOf(new Set([1])); // true a.isDisjointFrom(new Set([9])); // true ``` Two properties matter more than the names. First, **the four combining methods return a brand-new Set and mutate nothing** — `a` and `b` are unchanged, which makes them safe to chain. Second, **the three predicates return booleans**, not Sets. ## The set-like requirement The argument is not required to be a `Set`, but it must be *set-like*: an object exposing a numeric `size` property, a callable `has`, and a callable `keys` that returns an iterator. This is the detail interviewers probe, because the obvious mistake fails loudly: ```js new Set([1, 2]).union([2, 3]); // TypeError — an array has no size property new Set([1, 2]).union(new Set([2, 3])); // fine ``` A `Map` happens to satisfy the protocol, and since the methods read `keys()`, `someSet.intersection(someMap)` operates on the Map's **keys**. If you have an array, wrap it: `a.union(new Set(arr))`. The receiver, by contrast, must be a real `Set` — these are `Set.prototype` methods that touch internal slots, so calling them on a set-like object throws. ## Doing it by hand The manual versions predate the methods and still appear constantly in code that targets older baselines, in interview whiteboards, and wherever the input is an array rather than a Set: ```js const union = (a, b) => new Set([...a, ...b]); const intersection = (a, b) => new Set([...a].filter(x => b.has(x))); const difference = (a, b) => new Set([...a].filter(x => !b.has(x))); const symmetricDifference = (a, b) => new Set([...difference(a, b), ...difference(b, a)]); ``` They work because a Set is iterable — spread drains its values in insertion order — and because `has` performs the same SameValueZero lookup the built-ins use. Note that `difference` is **asymmetric**: `difference(a, b)` is what is in `a` and not in `b`, which is not the same as `difference(b, a)`. Candidates routinely conflate that with symmetric difference, which is the union of both one-sided differences. The predicates are equally short by hand: ```js const isSubsetOf = (a, b) => [...a].every(x => b.has(x)); const isDisjointFrom = (a, b) => ![...a].some(x => b.has(x)); ``` ## Ordering and identity The results are Sets, so they iterate in the order their values were inserted while being built; `union` naturally lists the receiver's values first, then whatever the other operand contributes that was not already there. Do not build logic on a precise ordering of `intersection` — treat the result as an unordered collection and sort explicitly if presentation order matters. Membership across all of these is the Set's own equality: `NaN` matches `NaN`, `+0` and `-0` are one value, and objects match only by reference. So intersecting two arrays of freshly-parsed objects yields an empty Set no matter how similar the contents look; map to identity keys first. ## Choosing between them When your runtime baseline includes the methods, prefer them: they say what they mean, avoid building intermediate arrays, and let the engine iterate the smaller collection where that is legal. Reach for the hand-rolled versions when you must support an older baseline, when your inputs are arrays you would otherwise have to wrap anyway, or when the "set" is really a domain concept — dedupe by id, diff two API payloads — where you want the filter predicate to be something richer than raw value equality.