Off the top of my head, numbers get stringified when used as keys in objects. === and !== are almost always what you want instead of == and !=. It's generally

Off the top of my head, numbers get stringified when used as keys in objects. === and !== are almost always what you want instead of == and !=. It's generally too eager to stringify values when the programmer is doing something a bit suspect. For some use cases, it's also annoying that you get undefined instead of an exception when you attempt to access a missing object property, along with undefined == null being very annoying for similar reasons. I used to work on executing JavaScript as part of Google's indexing infrastructure. Some webmasters saw tons of errant URLs with "undefined" and "NaN" in them when Google first started crawling the URLs discovered via JavaScript. It would have been too much work for me to implement full data flow dependency tracking in SpiderMonkey, so I modified the typecast code to perform data flow analysis at the type level. If undefined was ever cast to Number, then all numbers were suspect. If undefined was ever cast to String, then all Strings were suspect. If Number was suspect and NaN was ever cast to String, then all Strings were suspect. We stopped keeping track of generated URLs if Strings became suspect. I put in a few heuristics to cover some common patterns to avoid making things overly suspect, and that seemed to work pretty well. In any case, it would have been better from a dynamic analysis standpoint (and easier on webmasters and their webservers) had JavaScript been more liberal in throwing exceptions instead of trying to limp along after hitting an error.