NaN behavior in JS is defined in the IEEE standard for floating-point numbers and should be the same in any language.<p>Any two values can be <i>less than</i>, <i>equal</i>, <i>greater than</i>, or <i>unordered</i>. The > operation, for example, evaluates to true if its operands are <i>greater than</i>. Per IEEE 754, "every NaN shall compare <i>unordered</i> with everything, including itself." By making NaN comparisons <i>unordered</i>, positive comparisons always evaluate as false. "Is 5 > NaN? No. Is NaN > 5? No." Same for ==. But negated comparisons are always true by consequence; since A != B is the same as !(A == B), anything != NaN is true.<p>One could argue that the spec should have special-cased NaN for the == operator (which as defined is only true if the comparison is <i>equal</i>, and not <i>unordered</i>), but they did not.
Thanks for the thoughtful write-up—always interesting to revisit JavaScript's quirks and strengths through someone else's lens.<p>That said, I think a few of the issues highlighted, while valid, might not be as disruptive in modern practice as they used to be. For instance, the typeof null === "object" behavior is certainly unfortunate, but it's well-understood at this point, and most tooling/linting setups help you avoid tripping over it. Similarly, Array.prototype.sort() sorting lexicographically by default feels odd until you remember JavaScript’s history as a primarily string-focused scripting language. These days, providing a comparator is second nature for most devs working with numeric arrays.<p>The point about accidentally declaring globals is a good one—but thankfully, with ES modules, use strict as the default, and tools like TypeScript, it’s much harder to make that mistake in modern codebases.<p>That said, I really appreciate the focus on JavaScript’s virtues, like closures, async/await, and overall flexibility—those really are part of what makes the language so enjoyable despite its rough edges.<p>I'm curious—have you built or maintained any large-scale JavaScript or TypeScript codebases recently? If so, what were the biggest pain points you ran into? Do the quirks you mention tend to surface in real-world projects at scale, or are they more theoretical annoyances that pop up in isolated cases?<p>There are definitely still many challenges in the language, but the ecosystem has come a long way, and it seems like it's still evolving in the right direction. Hopefully JavaScript keeps improving—both in language design and developer ergonomics—without losing what makes it so approachable in the first place.
What I don't like is lack of features that would erase whole classes of software around it. For example, function environments (substitute the global scope with another object for a single invocation) could delete lots of code and paradigm from vue/rx-likes.<p>It also neither supports operator overloads (good thing in general) nor has a decimal type which is a must for human numbers like euros and kilograms. Rather it includes the mostly useless bigint.<p>It also does nothing to fix the mentioned quirks like sort(). It could e.g. include cmp(a, b), and propcmp(name[,cmp]) off the shelf so the issue wasn't wordy at least: nums.sort(cmp), objs.sort(propcmp("id")).