I'd like to understand why `document.all` is slower than `getElementById`. Couldn't any even somewhat decent optimizing compiler trivially compile the first to the latter? Like, I don't mean in weird cases like `const all = document.all; return all[v]`, or iterating over it, just the general one where someone directly does `document.all.foo` or `document.all[v]`, ie the 99.99% case. When faced with the choice to compile those accesses to getElementById calls, or patch the ecmascript standard to put IE-compat workarounds in there, it seems kinda nuts to me that they would choose the latter, so I bet there'a good reason that I'm missing.
On JavaScript's Weirdness
11–20 of 85 posts
Re: On JavaScript's Weirdness
#12The list of "other weirdness" at the end mentions:
> +0 vs. -0
Which feels kind of odd, since that's mostly floating point weirdness, not JS weirdness. Unless they mean the fact that you can force V8 to initialize a zero-value as a double using -0 as a literal (it tends to optimize 0 to integers). But that has no effect on real-world code unless you use Math.sign, or divide by minus zero.
Re: On JavaScript's Weirdness
#13 “JavaScript sucks because '0' == 0!”
- literally everyone ever
Re: On JavaScript's Weirdness
#14[deleted]
Re: On JavaScript's Weirdness
#15“JavaScript sucks because '0' == 0!” - literally everyone ever I never really understood the hate for this, given that everything is a string in HTTP, and that SQL does the same damn thing. There are far more annoying things about JS (both the language and the ecosystem).
The article didn't even mention it. If you actually read, it's more about things that are not necessarily too annoying from a programmer's pespective, but is very much for anyone working on the platform.
Re: On JavaScript's Weirdness
#16I'd forgive a few of those. Unicode is Unicode. The for loop capture behaviour makes sense to me. Missing semis should also be in your linter. Sparse arrays is the sort of feature you'd read up on if you use and not rely on intuition. It makes sense that if you loop over a sparse thing the looping is sparse too.
Since I started using Prettier, I've moved permanently into the no-semicolons camp. Prettier catches ASI hazards and inserts semicolons where needed, and I've never seen it fail. Whichever camp you're in though, put it in your linter, don't leave it to chance. React code is full of array destructuring, that particular hazard is prone to bite you if you ignore it (tho it's still a little contrived if your usual style…
The rules are not that many, you can omit semicolons everywhere except 1. Before open square bracket 2. Before open parenthesis.
That's it, those are the only 2 edge cases.
Re: On JavaScript's Weirdness
#17 function f1(a:number, b:number, c:number, d:number) {
[a, b] = [b, a]
[c, d] = [d, c]
console.log(a, b, c, d)
}
Re: On JavaScript's Weirdness
#18I can pretty confidently say that every article I have seen in the past 5 years that complain about weirdness of JavaScript is about things that you would never do in a modern, production-level codebase. Many of these issues are about pre-ES6, outdated practice (e.g. eval, using == operator) that are almost certainly going to be flagged by a linter. Very occasionally, you do get hit by some weirdness, but likely doesn't take more than a few minutes to figure out. And if you write in TypeScript, like almost every serious new project created these days, most of these questions don't exist at all.
Which is why I don't bother reading these posts any more.
Re: On JavaScript's Weirdness
#19Many mistakes in section 2. The author seems to fundamentally misunderstand block scoping vs lexical scoping, and interactions when deferring execution to the next run of the event loop. In the first example: for (let i = 0; i console.log(i)); } // prints "0 1 2" — as expected let i = 0; for (i = 0; i console.log(i)); } // prints "3 3 3" — what? i's scope is outside the for loop in the second example, and the setTime…
This sort of stuff is very explicit and unsurprising in C++ (and to a lesser extent Rust), but it's always confusing in languages that leave the capturing details implicit. Even Go got bitten by this and it doesn't even JavaScript's broken `var`.
Re: On JavaScript's Weirdness
#20These are the well known bad parts every JS learner is taught about from numerous sources. I guess its OK to repeat the basics, but the linked article looks more like a blog spam rehash.