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

1–10 of 85 posts

Re: On JavaScript's Weirdness

#2

Post by blatantly »

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.

Re: On JavaScript's Weirdness

#3

Post by chuckadams »

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.

Re: On JavaScript's Weirdness

#4

Post by nobleach »

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.

Re: On JavaScript's Weirdness

#5

Post by glenjamin »

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

Re: On JavaScript's Weirdness

#6

Post by chuckadams »

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 is avoiding mutable variables).

Re: On JavaScript's Weirdness

#7

Post by CharlieDigital »

chuckadams wrote: post #3

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

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/

Re: On JavaScript's Weirdness

#8

Post by pcthrowaway »

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 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  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 setTimeout(()=>console.log(x))
      )(i)
    }
    // prints 1 2 3

Re: On JavaScript's Weirdness

#9

Post by chuckadams »

CharlieDigital wrote: post #7
chuckadams wrote: post #3

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

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 ;)

Re: On JavaScript's Weirdness

#10

Post by Joker_vD »

glenjamin wrote: post #5

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

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.

Post reply on HN