Objects not really safe to use as sets:

    const x = {};
    ‘constructor’ in x // true
    x[‘constructor’] === Object // true

You have to use hasOwnProperty and people don’t remember to do this.

Some properties cannot be deleted, and some cannot be modified:

    delete x.constructor;
    x.constructor === undefined // false
    x.__proto__ = undefined;
    x.__proto__ === undefined // false

Sets also allow you to have sets of other types rather than just strings and symbols.

If you do use objects I might suggest Object.create(null).

+1 Was going to be my response as well...

Yup. I always use Set and Map over objects. They just contain way fewer surprises and the APIs actually work as you would expect. I only use Objects for "struct" like objects with a known set of keys that are used by name. It is also nice because it conveys more intent to the reader.

Ditto!!!

It's a pretty straightforward way to do things like avoiding duplicates or checking if an item is part of a collection without using quadratic loops or string-keyed dictionary objects.

It's O(1) for the latter (edit: I stand corrected, but probably close, as per spec).

Conversion to and from arrays even preserves order.

So I don't see these two use cases as "showing off", why should anybody do that?

I have only used JS sets in interviews to avoid duplication - more than once, the interviewer has chuckled appreciatively and directed me to not use them (being too easy)

That would be a red flag for me in most cases, as the person being interviewed. If the interview is to gauge my knowledge of Javascript, then using sets should be in my favor since I'm using the most optimized approach to demonstrate I know the language well and can adequately do the job. If it's "not acceptable", then what is the goal there? To wrack my brain as part of some pseudo intelligence test? Shall we break it down to 1s and 0s too?

It can be a point in your favour but also something that you are asked to avoid. You both showed good knowledge and default choices and showed that you can implement a simple algorithm from scratch. Both are valuable points about your skills.

The main "result" of the interview shouldn't just be "does the code work". The process is far, far more important for understanding how you write code.

Fair, and that's actually the opposite of using them to show off, right? :)

You can use objects and other things as keys for a Set or Map. As far as I know you can't do that for objects.

    const s = new Set();

    const a = {}, b = {};

    s.add(a);

    s.has(a); // true

    s.has(b); // false


    const o = {};

    o[a] = true;

    o[a]; // true

    o[b]; // true, cause its cast to a string like "[object Object]"

I've also seen Map perform faster than using an object as a Map.

Beware of a gotcha here: object keys are tested for strict equality and not deep equality, in other words add/get must use the same object instance and not just an object with the same keys/values

I've used them occasionally to clarify the semantics of collections; I like being able to express that some collection of values is unordered and has only unique elements.