Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

On JavaScript's Weirdness

stack-auth.com

Post reply on HN
Print view View original

21–30 of 85 posts

Re: On JavaScript's Weirdness

#21

Post by sapiogram »

pcthrowaway wrote: post #8

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 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…

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.

Re: On JavaScript's Weirdness

#22

Post by cess11 »

chuckadams wrote: post #9
CharlieDigital wrote: post #7

Earlier quoted context omitted.

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…

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.

Re: On JavaScript's Weirdness

#23

Post by sapiogram »

rs186 wrote: post #18

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 does…

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%.

Re: On JavaScript's Weirdness

#24

Post by davidmurdoch »

skrebbel wrote: post #11

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 comp…

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.

Re: On JavaScript's Weirdness

#25

Post by smjburton »

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.

Re: On JavaScript's Weirdness

#26

Post by [deleted] »

sapiogram wrote: post #23
rs186 wrote: post #18

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 does…

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]

Re: On JavaScript's Weirdness

#27

Post by Philpax »

rs186 wrote: post #18

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 does…

You should have probably read the post.

Re: On JavaScript's Weirdness

#28

Post by sapiogram »

IshKebab wrote: post #19
pcthrowaway wrote: post #8

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 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`.

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.

Re: On JavaScript's Weirdness

#29

Post by troupo »

nobleach wrote: post #4

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.

Re: On JavaScript's Weirdness

#30

Post by hombre_fatal »

chuckadams wrote: post #6
blatantly wrote: post #2

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…

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.

Post reply on HN