TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

What I don't like in JavaScript

8 点作者 senfiaj29 天前

3 条评论

mubou29 天前
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 &gt; operation, for example, evaluates to true if its operands are <i>greater than</i>. Per IEEE 754, &quot;every NaN shall compare <i>unordered</i> with everything, including itself.&quot; By making NaN comparisons <i>unordered</i>, positive comparisons always evaluate as false. &quot;Is 5 &gt; NaN? No. Is NaN &gt; 5? No.&quot; 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.
评论 #43706253 未加载
评论 #43703100 未加载
loige29 天前
Thanks for the thoughtful write-up—always interesting to revisit JavaScript&#x27;s quirks and strengths through someone else&#x27;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 === &quot;object&quot; behavior is certainly unfortunate, but it&#x27;s well-understood at this point, and most tooling&#x2F;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&#x2F;await, and overall flexibility—those really are part of what makes the language so enjoyable despite its rough edges.<p>I&#x27;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&#x27;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.
wruza29 天前
What I don&#x27;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&#x2F;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&#x27;t wordy at least: nums.sort(cmp), objs.sort(propcmp(&quot;id&quot;)).
评论 #43706341 未加载
评论 #43704216 未加载