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
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`.
I don't think it's fair to call Go and Javascript's behavior "implicit", they just always capture variables by reference.
Rust variable capture is implicit though, but it can't cause the problems described in the article, since mutable references are required to be unique.
In JavaScript,
a 'let' inside the initializer of a for loop is captured by value, all the others are captured by reference.
I think it's fair to call that semantics "implicit".
No, that's a mistake in the article. The variable is still captured by reference, but `let` is causing it to be re-declared on every iteration of the loop, not mutated.
The following code prints 1, 2, 3. It wouldn't do that if the variable was captured by value.
for (let i = 0; i < 3;) {
setTimeout(() => console.log(i));
i++;
}
consider this
for (let i=0;i<3;i++) {
i+=10;
setTimeout(_=>console.log(i),30);
i-=10
}
Capture by value would print 10, 11, 12 that's the value when it was captured
Capture by reference would print 0,1,2
It's much easier to conceptualise it as
for (const i=0;i<3;i++) {
setTimeout(_=>console.log(i),30);
}
which is fine because i never changes. It is a different i each time.
The author's explanation seems perfectly correct to me. Where does he "misunderstand block scoping vs lexical scoping"? By the Wikipedia definition:
> lexical scope is "the portion of source code in which a binding of a name with an entity applies".
...both `let` and `var` are lexically scoped, the scopes are just different.
FWIW, I think the parent meant "function scoping vs lexical scoping" rather than "block scoping vs lexical scoping". You're correct that function scoping is technically a form of lexical scoping (where the scope is the function), but if you want to be _really_ pedantic, the ecma262 considers let/const to be "lexical binding"[0] as opposed to var being a "variable declaration"[1], where the former declares in the "Lexical Environment" while the latter declares in the "Variable Environment". These happen to be the same environment record on function entry.
Thanks for the links, that adds a lot of important context.
However, there's no notion of the first example operating on a single scope and the latter on three different, individual scopes. Which is why scope ranges and where you declare a variable with `let` matters.
I remember properly learning JS from “The Good Parts” book, which makes it known from the start that JS is a nasty language but if you ignore many sharp edges it can be nice and elegant. I think this is especially true with (a subset of) TS. All you need is a very, very strict linter, and then you get to pretend you’re working in a mostly solid language.
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.
The eval thing is listed as a potential performance cost, but it's actually super important for performance, because it allows the parser to statically know that sloppy eval is never called inside a function, and that variables can therefore be optimized away.
I 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.
If you actually opened the article, I think you would find it interesting. I agree that a well-configured eslint catches 99% of the weirdness, but this article tries to be about the remaining 1%.
[deleted]
If the language needs a linter to keep otherwise-competent developers from introducing potentially maddening bugs into the codebase, it's weird.
JS was developed in a hurry and has been extended into doing things it was never meant to do, and it shows.
You should have probably read the post.
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.
wat video was intended to be funny and tongue in cheek.
While interesting and possibly helpful to new coders, are these quirks of the language still relevant when most development in Javascript is done using a framework (React, Vue, etc) these days? How often do these "gotchas" factor into "modern" Javascript development, especially in production? These type of articles seem to critique mechanics of the language that don't come up as often in practice.
You are right, these quirks are not something you struggle with very often. The only one that has been troublesome at some point during my now 8 years as a professional, mainly Javascript with Vue, web developer is the automatic semicolon insertion example.
The simplest fixes for it is to just insert semicolons yourself, always use const, and not start any lines with [ or (.
The issue with variables and loops that OP described is worse with React, since you create closure inside the render function for event handlers, and if that closure captures any state variables (rather than a getter function for example), then you'll end up referencing stale state. React relies on linters to protect against this, but that only goes so far and the API design makes it easy to screw up, so you have to be on your toes.
Edit: To be clear, this is specifically a React hooks problem, not the old React with classes.
That's a fair point. Adding that to the original post would help provide context about why some of these quirks are still relevant to consider even when using a framework. I believe the assumption is often that frameworks abstract the Javascript "weirdness" away.
It's worse in a framework, in the framework you need to know the oddities of the language as well as how the framework manages them.
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.
Fun fact: JavaScript 1.2 did feature -0 and 0 = +0. Which has quite a number of rather confusing aspects and effects, if you run a script in this context.
I don't mind '0' == 0 when it's used for scripts and dumb stuff. That's literally how shellscript works, and I love shellscript, so I can't complain about that.
But I would never use shellscript to build an entire business's user interface with a giant shellscript framework. That would be insane. A language that was designed as a throwaway scripting thing for doing some miscellaneous tasks, and never designed for full application purposes? No sane person would use that for a business's core product.
For the above codes Typescript gives error message: Type 'number[]' is not assignable to type 'number'.
“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).
Moreover, it was kind of a standard for any scripting language at that time. In other words, this was generally expected behavior. (E.g., compare AWK, Perl, etc.)
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.
> The article didn't even mention it.
Literal first thing in the article - it's a block quote right under the title.
These 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.
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).
I can't think of any typical case where you're destructuring arrays in React without const/let.
The only time you start a line with a delimiter in JS that I can think of is a rare case like `;[1,2,3].forEach(...)` which also isn't something you do in React.
While I still hate semis, these days my approach to formatting is just `echo {} > .prettierrc` and using the defaults. It's a nice balance where I never write a semicolon myself, and I never have to dick around with config.
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.
Instead of learning a rule and then memorizing exceptions to it, you could just learn a rule with no exceptions.
And yet, per the spec, new syntax features are allowed to break ASI:
> As new syntactic features are added to ECMAScript, additional grammar productions could be added that cause lines relying on automatic semicolon insertion preceding them to change grammar productions when parsed.
So really, the rules are “there are currently 2 exceptions and an infinite number allowed to be added at any time”. To me, that’s worth letting prettier auto-insert semicolons when I hit save.
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.
There was a time where there weren't optimizing compilers in JS engines, at least not anywhere near the level of sophistication they are at today.
In V8, not too long ago, any function over 400 characters, including comments, would bail out of optimization. We had lint rules to disallow these "long" functions.
Regarding that choice: Given that this is really a different library (the DOM and its individual browser implementation), it's probably quite sane to just define a certain object to evaluate as falsy, as compared to any attempts to check for a certain implementation in this external library for any call.
(Even more so, since any access using `document.all` retrieves an object from a live collection, while the other access method is a function call, which is a totally different thing.)
[deleted]
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'm thinking Kotlin for my next backend project. Or maybe Unison ;)
I prefer Java because I know it better, but Kotlin is nice. I'd prefer it over .NET, which is still kind of messy unless you're doing some quite specific things where the multi platform efforts have actually succeeded. F# is fine for small tools and some CLI stuff, but big frameworky things tend to be a mess or MICROS~1 specific.
Some people are likely to claim it's not the case anymore and so on, but it's my recent experience on Debian. The JVM environment has its warts and Maven sometimes feels like a huge dumb golem but at least it doesn't come across as whiny or make you feel like a second class citizen.
Both JS and PHP are rather footgun-rich languages; have you tried Python, Java, Kotlin, or C#?
> have you tried Python, Java, Kotlin, or C#?
Yes, plenty of experience in the first two, but the last two are better contenders. At any rate I work primarily with TS when I do front-end code, it's very rare for me to write raw JS, so a lot of footguns automatically go away.
> In any programming language, when you capture values with a lambda/arrow function
It seems like just a few years ago that few programmers knew what these concepts are: mostly just the few that were exposed to Lisp or Scheme in college.
Now it's in "any language" and we have to be exposed to incorrect mansplaining about it from a C++ point of view.
> there are two ways to pass variables: By value (copy) or by reference (passing a pointer). Some languages, like C++, let you pick:
Lexical capture isn't "pass".
What this person doesn't understand is that C++ lambdas are fake lambdas, which do not implement environment capture. C++ lambdas will not furnish you with a correct understanding of lambdas.
(Furthermore, no language should ever imitate what C++ has done to lambdas.)
Capture isn't the passage of arguments to parameters, which can be call by value or reference, etc.
Capture is a retention of the environment of bindings, itself.
The issue here is simply that
1. The Javascript lambda is correctly implementing lexical capture.
2. The Javascript loop is not creating a fresh binding for the loop variable in each iteration. It binds one variable, and mutates its value.
Mutating the value is the correct thing to do for a loop construct which lets the program separately express initialization, guard testing and increment. The semantics of such a loop requires that the next iteration's guard have access to the previous iteration's value. We can still have hacks under the hood so that a lexical closure will capture a different variable in each iteration, but it's not worth it, and the program can do that itself. Javascript is doing the right thing here, and it cannot just be fixed. In any case, vast numbers of programs depend on the variable i being a single instance that is created and initialized once and then survives from one iteration to the next.
Now lambdas can in fact be implemented by copy. Compilers for languages with lambda can take various strategies for representing the environment and how it is handled under capture. One possible mechanism is conversion to a flattened environment vector, whereby every new lambda
gets a new copy of such a vector.
The entire nested lexical scope group becomes one object in which every variable has a fixed offset that the compiled code can refer to. You then have to treat individual variables in that flat environment according to whether any given variable is shared, mutated or both.
The worst case is when multiple closures capture the same variable (it is shared) and the variable is mutated such that one closure changes it and another one must see the change. This is the situation with the loop index i variable in the JS loop. This means that under a flat, copied environment strategy, the variable will have to be implemented as a reference cell in the environment vector.
Variables which are not mutated can just be values in the vector. Variables which are mutated, but not shared among closures, likewise.
This is all under the hood though; there are no programmer-visible annotations for indicating how to treat each captured variable. It always looks as if the entire environment at the point of capture is being taken by reference. The compiler generates reference semantics for those variables which need it.
At the implementation level, with particular strategies for handling environments under lambda, we can think about capturing references or value copies. C++ lambdas imitate this sort of implementation-level thinking and define the language construct around it, in a way that avoids the master concept of capturing the environment.
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)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`.
I don't think it's fair to call Go and Javascript's behavior "implicit", they just always capture variables by reference.
Rust variable capture is implicit though, but it can't cause the problems described in the article, since mutable references are required to be unique.
In JavaScript, a 'let' inside the initializer of a for loop is captured by value, all the others are captured by reference.
I think it's fair to call that semantics "implicit".
No, that's a mistake in the article. The variable is still captured by reference, but `let` is causing it to be re-declared on every iteration of the loop, not mutated.
The following code prints 1, 2, 3. It wouldn't do that if the variable was captured by value.
consider this
Capture by value would print 10, 11, 12 that's the value when it was capturedCapture by reference would print 0,1,2
It's much easier to conceptualise it as
which is fine because i never changes. It is a different i each time.The author's explanation seems perfectly correct to me. Where does he "misunderstand block scoping vs lexical scoping"? By the Wikipedia definition:
> lexical scope is "the portion of source code in which a binding of a name with an entity applies".
...both `let` and `var` are lexically scoped, the scopes are just different.
FWIW, I think the parent meant "function scoping vs lexical scoping" rather than "block scoping vs lexical scoping". You're correct that function scoping is technically a form of lexical scoping (where the scope is the function), but if you want to be _really_ pedantic, the ecma262 considers let/const to be "lexical binding"[0] as opposed to var being a "variable declaration"[1], where the former declares in the "Lexical Environment" while the latter declares in the "Variable Environment". These happen to be the same environment record on function entry.
[0] https://tc39.es/ecma262/#sec-let-and-const-declarations [1] https://tc39.es/ecma262/#sec-variable-statement
Thanks for the links, that adds a lot of important context.
However, there's no notion of the first example operating on a single scope and the latter on three different, individual scopes. Which is why scope ranges and where you declare a variable with `let` matters.
I remember properly learning JS from “The Good Parts” book, which makes it known from the start that JS is a nasty language but if you ignore many sharp edges it can be nice and elegant. I think this is especially true with (a subset of) TS. All you need is a very, very strict linter, and then you get to pretend you’re working in a mostly solid language.
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.
The eval thing is listed as a potential performance cost, but it's actually super important for performance, because it allows the parser to statically know that sloppy eval is never called inside a function, and that variables can therefore be optimized away.
I 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.
If you actually opened the article, I think you would find it interesting. I agree that a well-configured eslint catches 99% of the weirdness, but this article tries to be about the remaining 1%.
If the language needs a linter to keep otherwise-competent developers from introducing potentially maddening bugs into the codebase, it's weird.
JS was developed in a hurry and has been extended into doing things it was never meant to do, and it shows.
You should have probably read the post.
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.
wat video was intended to be funny and tongue in cheek.
While interesting and possibly helpful to new coders, are these quirks of the language still relevant when most development in Javascript is done using a framework (React, Vue, etc) these days? How often do these "gotchas" factor into "modern" Javascript development, especially in production? These type of articles seem to critique mechanics of the language that don't come up as often in practice.
You are right, these quirks are not something you struggle with very often. The only one that has been troublesome at some point during my now 8 years as a professional, mainly Javascript with Vue, web developer is the automatic semicolon insertion example.
The simplest fixes for it is to just insert semicolons yourself, always use const, and not start any lines with [ or (.
The issue with variables and loops that OP described is worse with React, since you create closure inside the render function for event handlers, and if that closure captures any state variables (rather than a getter function for example), then you'll end up referencing stale state. React relies on linters to protect against this, but that only goes so far and the API design makes it easy to screw up, so you have to be on your toes.
Edit: To be clear, this is specifically a React hooks problem, not the old React with classes.
That's a fair point. Adding that to the original post would help provide context about why some of these quirks are still relevant to consider even when using a framework. I believe the assumption is often that frameworks abstract the Javascript "weirdness" away.
It's worse in a framework, in the framework you need to know the oddities of the language as well as how the framework manages them.
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.
Fun fact: JavaScript 1.2 did feature -0 and 0 = +0. Which has quite a number of rather confusing aspects and effects, if you run a script in this context.
I don't mind '0' == 0 when it's used for scripts and dumb stuff. That's literally how shellscript works, and I love shellscript, so I can't complain about that.
But I would never use shellscript to build an entire business's user interface with a giant shellscript framework. That would be insane. A language that was designed as a throwaway scripting thing for doing some miscellaneous tasks, and never designed for full application purposes? No sane person would use that for a business's core product.
Right?
Moreover, it was kind of a standard for any scripting language at that time. In other words, this was generally expected behavior. (E.g., compare AWK, Perl, etc.)
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.
> The article didn't even mention it.
Literal first thing in the article - it's a block quote right under the title.
These 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.
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).
I can't think of any typical case where you're destructuring arrays in React without const/let.
The only time you start a line with a delimiter in JS that I can think of is a rare case like `;[1,2,3].forEach(...)` which also isn't something you do in React.
While I still hate semis, these days my approach to formatting is just `echo {} > .prettierrc` and using the defaults. It's a nice balance where I never write a semicolon myself, and I never have to dick around with config.
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.
Instead of learning a rule and then memorizing exceptions to it, you could just learn a rule with no exceptions.
And yet, per the spec, new syntax features are allowed to break ASI:
> As new syntactic features are added to ECMAScript, additional grammar productions could be added that cause lines relying on automatic semicolon insertion preceding them to change grammar productions when parsed.
So really, the rules are “there are currently 2 exceptions and an infinite number allowed to be added at any time”. To me, that’s worth letting prettier auto-insert semicolons when I hit save.
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.
There was a time where there weren't optimizing compilers in JS engines, at least not anywhere near the level of sophistication they are at today.
In V8, not too long ago, any function over 400 characters, including comments, would bail out of optimization. We had lint rules to disallow these "long" functions.
Regarding that choice: Given that this is really a different library (the DOM and its individual browser implementation), it's probably quite sane to just define a certain object to evaluate as falsy, as compared to any attempts to check for a certain implementation in this external library for any call.
(Even more so, since any access using `document.all` retrieves an object from a live collection, while the other access method is a function call, which is a totally different thing.)
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 prefer Java because I know it better, but Kotlin is nice. I'd prefer it over .NET, which is still kind of messy unless you're doing some quite specific things where the multi platform efforts have actually succeeded. F# is fine for small tools and some CLI stuff, but big frameworky things tend to be a mess or MICROS~1 specific.
Some people are likely to claim it's not the case anymore and so on, but it's my recent experience on Debian. The JVM environment has its warts and Maven sometimes feels like a huge dumb golem but at least it doesn't come across as whiny or make you feel like a second class citizen.
Both JS and PHP are rather footgun-rich languages; have you tried Python, Java, Kotlin, or C#?
> have you tried Python, Java, Kotlin, or C#?
Yes, plenty of experience in the first two, but the last two are better contenders. At any rate I work primarily with TS when I do front-end code, it's very rare for me to write raw JS, so a lot of footguns automatically go away.
> In any programming language, when you capture values with a lambda/arrow function
It seems like just a few years ago that few programmers knew what these concepts are: mostly just the few that were exposed to Lisp or Scheme in college.
Now it's in "any language" and we have to be exposed to incorrect mansplaining about it from a C++ point of view.
> there are two ways to pass variables: By value (copy) or by reference (passing a pointer). Some languages, like C++, let you pick:
Lexical capture isn't "pass".
What this person doesn't understand is that C++ lambdas are fake lambdas, which do not implement environment capture. C++ lambdas will not furnish you with a correct understanding of lambdas.
(Furthermore, no language should ever imitate what C++ has done to lambdas.)
Capture isn't the passage of arguments to parameters, which can be call by value or reference, etc. Capture is a retention of the environment of bindings, itself.
The issue here is simply that
1. The Javascript lambda is correctly implementing lexical capture.
2. The Javascript loop is not creating a fresh binding for the loop variable in each iteration. It binds one variable, and mutates its value.
Mutating the value is the correct thing to do for a loop construct which lets the program separately express initialization, guard testing and increment. The semantics of such a loop requires that the next iteration's guard have access to the previous iteration's value. We can still have hacks under the hood so that a lexical closure will capture a different variable in each iteration, but it's not worth it, and the program can do that itself. Javascript is doing the right thing here, and it cannot just be fixed. In any case, vast numbers of programs depend on the variable i being a single instance that is created and initialized once and then survives from one iteration to the next.
Now lambdas can in fact be implemented by copy. Compilers for languages with lambda can take various strategies for representing the environment and how it is handled under capture. One possible mechanism is conversion to a flattened environment vector, whereby every new lambda gets a new copy of such a vector.
The entire nested lexical scope group becomes one object in which every variable has a fixed offset that the compiled code can refer to. You then have to treat individual variables in that flat environment according to whether any given variable is shared, mutated or both.
The worst case is when multiple closures capture the same variable (it is shared) and the variable is mutated such that one closure changes it and another one must see the change. This is the situation with the loop index i variable in the JS loop. This means that under a flat, copied environment strategy, the variable will have to be implemented as a reference cell in the environment vector. Variables which are not mutated can just be values in the vector. Variables which are mutated, but not shared among closures, likewise.
This is all under the hood though; there are no programmer-visible annotations for indicating how to treat each captured variable. It always looks as if the entire environment at the point of capture is being taken by reference. The compiler generates reference semantics for those variables which need it.
At the implementation level, with particular strategies for handling environments under lambda, we can think about capturing references or value copies. C++ lambdas imitate this sort of implementation-level thinking and define the language construct around it, in a way that avoids the master concept of capturing the environment.
My favorite one ever:
017 == '17' // false
018 == '18' // true