In JS there are a pair of Stage 1 proposals to increase support for richer/more complex keys in collections like Map: https://github.com/tc39/proposal-richer-ke

In JS there are a pair of Stage 1 proposals to increase support for richer/more complex keys in collections like Map: https://github.com/tc39/proposal-richer-keys https://github.com/tc39/proposal-richer-keys Strings seem really easy for composite keys and "deep comparison" for objects, but you could do more like C# actually does under the hood which is compute simple hash numbers (getting back to the article's point that computers are often faster with number calculations than string work). C# does most of its equality "magic" with GetHashCode() (surprisingly not Equals() and obviously not ToString()). (Relatedly this is why C# linters will yell at you if you override Equals but not also GetHashCode. Equals seems the more "useful" override but GetHashCode is the actual work horse.) Most implementations of GetHashCode (even for deep comparison situations) are generally starting with some random prime constant XOR bits of all the data and return the integer you have left after all the XORs. You can do the same thing in JS today if you wish. Modern .NET now has a nice System.HashCode helper class for doing it quickly with a lot of good best practices baked in (a strong starting constant, for instance), so it's easy to forget the bad old days of writing all those XORs by hand, and .NET has always had GetHashCode a required method of System.Object so "recursion" of hashcodes is guaranteed to be simple. But those things aside, it's still really easy to compute hash codes by hand in JS to use for comparisons than to use string manipulation, if you put your mind to it.