The 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.
Complaining about the for loop behaviour seems odd. Variables declared in the expression section of the loop are scoped to the loop body - this is generally reasonable and the least likely to produce errors.
Notably, Go initially decided to stick with the C-style approach and have the scope be outside the loop, and has since decided that the tiny performance improvement this provides isn't worth the many many times it's tripped people up, and has changed the semantics in recent versions: https://go.dev/blog/loopvar-preview
Go's behaviour never made much sense because, unlike JS/C#/Java, Go has pointers. So if you really want to capture the variable itself and not its current value at the specific iteration, you can (and should) just capture the pointer to it.
But even in C#/Java/JS, it never made much sense either since a) you almost always want to capture the current value, not variable itself; b) if you really want the variable itself, you can put it into a 1-element array and capture the array (which how people evade Java's requirement that the captured variables must be "final" anyway) and use arr[0] everywhere instead.
I find these oddities far more realistic than the Wat video from a long time ago. Many of the things in that video had me asking, "sure but...what programmer would blindly try these things and then be shocked when they didn't work?" The examples in this article are actual "gotchas" that could silently bite someone.
I've a few opinions on the content, but I'm most interested in which unicode analyzer tool generated that nifty text tree diagram.
I can deal with JS's warts because the tooling is so much better. The other language I make my living with is PHP, and while it's much improved from before, the global function namespace is still a garbage fire, and you need extra linters like phpstan-safe-rule to force you to use sane wrappers.
For backend work, I'd recommend giving C# a look. Syntactically similar to TypeScript[0] but for any serious work, having runtime types and some of the facilities of .NET (e.g. Roslyn, expression trees, Entity Framework Core, threads, etc.) is really nice.
I recently moved from a C# backend startup to a TS backend startup and the lack of runtime types is a real friction point I feel every day with how the code has to be written (e.g. end up writing a lot of Zod; other projects have different and varying types of drudgery with regards to meta-typing for runtime)
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.
I'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 is avoiding mutable variables).
Many 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 < 3; i++) {
setTimeout(() => console.log(i));
}
// prints "0 1 2" — as expected
let i = 0;
for (i = 0; i < 3; i++) {
setTimeout(() => console.log(i));
}
// prints "3 3 3" — what?
i's scope is outside the for loop in the second example, and the setTimeouts execute in the call stack (e.g. the next run of the event loop), after i has finished incrementing in the first event loop iteration
Consider that you'd have the same issue with the older `var` keyword which is lexically scoped
for (var i = 0; i < 3; i++) {
setTimeout(() => console.log(i));
}
// prints "3 3 3" because i is not block-scoped
If for some reason you really need some work run in the next call stack, and you need to use the value of a variable which is scoped outside the loop and modified inside the loop, you can also define a function (or use an iife) to pass the value of i in the current iteration into (rather than getting the reference of i in the event loop's next call stack)
let i = 0;
for (i = 0; i < 3; i++) {
(
(x)=>setTimeout(()=>console.log(x))
)(i)
}
// prints 1 2 3
The 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.
Complaining about the for loop behaviour seems odd. Variables declared in the expression section of the loop are scoped to the loop body - this is generally reasonable and the least likely to produce errors.
Notably, Go initially decided to stick with the C-style approach and have the scope be outside the loop, and has since decided that the tiny performance improvement this provides isn't worth the many many times it's tripped people up, and has changed the semantics in recent versions: https://go.dev/blog/loopvar-preview
Go's behaviour never made much sense because, unlike JS/C#/Java, Go has pointers. So if you really want to capture the variable itself and not its current value at the specific iteration, you can (and should) just capture the pointer to it.
But even in C#/Java/JS, it never made much sense either since a) you almost always want to capture the current value, not variable itself; b) if you really want the variable itself, you can put it into a 1-element array and capture the array (which how people evade Java's requirement that the captured variables must be "final" anyway) and use arr[0] everywhere instead.
I find these oddities far more realistic than the Wat video from a long time ago. Many of the things in that video had me asking, "sure but...what programmer would blindly try these things and then be shocked when they didn't work?" The examples in this article are actual "gotchas" that could silently bite someone.
I've a few opinions on the content, but I'm most interested in which unicode analyzer tool generated that nifty text tree diagram.
I can deal with JS's warts because the tooling is so much better. The other language I make my living with is PHP, and while it's much improved from before, the global function namespace is still a garbage fire, and you need extra linters like phpstan-safe-rule to force you to use sane wrappers.
For backend work, I'd recommend giving C# a look. Syntactically similar to TypeScript[0] but for any serious work, having runtime types and some of the facilities of .NET (e.g. Roslyn, expression trees, Entity Framework Core, threads, etc.) is really nice.
I recently moved from a C# backend startup to a TS backend startup and the lack of runtime types is a real friction point I feel every day with how the code has to be written (e.g. end up writing a lot of Zod; other projects have different and varying types of drudgery with regards to meta-typing for runtime)
[0] https://typescript-is-like-csharp.chrlschn.dev/
I'm thinking Kotlin for my next backend project. Or maybe Unison ;)
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.
I'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 is avoiding mutable variables).
Many 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:
i's scope is outside the for loop in the second example, and the setTimeouts execute in the call stack (e.g. the next run of the event loop), after i has finished incrementing in the first event loop iterationConsider that you'd have the same issue with the older `var` keyword which is lexically scoped
If for some reason you really need some work run in the next call stack, and you need to use the value of a variable which is scoped outside the loop and modified inside the loop, you can also define a function (or use an iife) to pass the value of i in the current iteration into (rather than getting the reference of i in the event loop's next call stack)